Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Stop Memsetting Structures

anmolsarma.in

Post reply on HN
Print view View original

271–277 of 277 posts

Re: Stop Memsetting Structures

#271

Post by Dylan16807 »

jcr1488 wrote: post #269
Dylan16807 wrote: post #266

Earlier quoted context omitted.

> As soon as a pointer to said memory is passed to an extern function in another translation unit, the compiler can't prove anything about how it's used, which is the case in pretty much all of the examples mentioned in this thread. You would have to call such a function between the memset and the first time you write to a member. Otherwise the compiler is allowed to say "I put the padding back, and you can't prove o…

> This is the kind of thing that can break by accident and ruin everyone's month. Not in practice. Compilers make use of undefined behaviour to optimize things that are widely applicable and profitable. No real compiler does what you're saying and no future compiler is likely to without explicitly being asked to. I agree that, by the letter of the spec, you're right, but you're still most certainly overstating the re…

It's just a type of dead store elimination. And objects are initialized so often that I could easily see it happening in the future. But I guess we'll just disagree on how likely it is.

Re: Stop Memsetting Structures

#272

Post by jcr1488 »

Dylan16807 wrote: post #271
jcr1488 wrote: post #269

Earlier quoted context omitted.

> This is the kind of thing that can break by accident and ruin everyone's month. Not in practice. Compilers make use of undefined behaviour to optimize things that are widely applicable and profitable. No real compiler does what you're saying and no future compiler is likely to without explicitly being asked to. I agree that, by the letter of the spec, you're right, but you're still most certainly overstating the re…

It's just a type of dead store elimination. And objects are initialized so often that I could easily see it happening in the future. But I guess we'll just disagree on how likely it is.

> It's just a type of dead store elimination

It's not just any, typical kind of dead store elimination. It also would require other optimization passes that I can assure you no mainstream compiler actually does. You can disagree with me if you want, but you're simply wrong.

Re: Stop Memsetting Structures

#273

Post by flohofwoe »

ogoffart wrote: post #237
flohofwoe wrote: post #18

Earlier quoted context omitted.

...are there any remaining architectures where NULL is not zero? The examples listed here are all historical: http://c-faq.com/null/machexamp.html

It does not matter if there are any architectures like that. Relying on that fact is still an undefined behavior. The compiler is allowed to produce any code it wants. If you use memset to initialize structure with pointers with 0 and then test if the pointer are NULL, the compiler could assume that the pointer was not properly initialized and remove the if completely, or actually even remove the whole function.

In the real world it rarely matter what a theoretical compiler is allowed to do, but what specific compilers actually do. UB only matters when compilers actually "exploit" it.

Re: Stop Memsetting Structures

#274

Post by Dylan16807 »

jcr1488 wrote: post #272
Dylan16807 wrote: post #271

Earlier quoted context omitted.

It's just a type of dead store elimination. And objects are initialized so often that I could easily see it happening in the future. But I guess we'll just disagree on how likely it is.

> It's just a type of dead store elimination It's not just any, typical kind of dead store elimination. It also would require other optimization passes that I can assure you no mainstream compiler actually does. You can disagree with me if you want, but you're simply wrong.

Lots of mainstream compilers already have passes that check if every field in an object is definitely assigned. They use this to provide errors or warnings.

That step is 90% of the work. Once you can do that, it's straightforward to assess that every field is assigned after a memset, with no intervening reads, and then remove the memset.

Re: Stop Memsetting Structures

#275

Post by jcr1488 »

Dylan16807 wrote: post #274
jcr1488 wrote: post #272

Earlier quoted context omitted.

> It's just a type of dead store elimination It's not just any, typical kind of dead store elimination. It also would require other optimization passes that I can assure you no mainstream compiler actually does. You can disagree with me if you want, but you're simply wrong.

Lots of mainstream compilers already have passes that check if every field in an object is definitely assigned. They use this to provide errors or warnings. That step is 90% of the work. Once you can do that, it's straightforward to assess that every field is assigned after a memset, with no intervening reads, and then remove the memset.

> That step is 90% of the work

I spent several years working on a production grade compiler and I can assure you it's not. But keep just making things up off the top of your head if it makes you feel smart.

Re: Stop Memsetting Structures

#276

Post by Dylan16807 »

jcr1488 wrote: post #275
Dylan16807 wrote: post #274

Earlier quoted context omitted.

Lots of mainstream compilers already have passes that check if every field in an object is definitely assigned. They use this to provide errors or warnings. That step is 90% of the work. Once you can do that, it's straightforward to assess that every field is assigned after a memset, with no intervening reads, and then remove the memset.

> That step is 90% of the work I spent several years working on a production grade compiler and I can assure you it's not. But keep just making things up off the top of your head if it makes you feel smart.

Would you care to explain why?

Let's look at a basic common case, as a checklist.

1. All fields are definitely assigned.

2. No functions are called except intrisics.

3. Nothing reads from the object on any control path.

4. Memset happens between creation and first assignment.

We agreed that step 1 is a solved problem, right? Are any of 2-4 difficult? Did I miss any prerequisites for the optimization?

Once you can prove 1-4, isn't the optimization pass as simple as looking for memsets applied to structs, checking 1-4, then deleting the call?

Re: Stop Memsetting Structures

#277

Post by [deleted] »

NikkiA wrote: post #164
jschwartzi wrote: post #4

I'll stop memsetting structures as soon as you support designated initializer lists in C++.

Apparently it's in C++20, so feel free to stop memsetting whenever you update your C++ compiler next (clang needs a flag to enable it, gcc has had it as part of it's c++2a support for 2 years)

[deleted]
Post reply on HN