There should be a warning for this enabled in every C project.
Re:GCC 5.2 released
by JoshTriplett on Thursday July 16, 2015 @01:52PM
(#9898776)
GCC has a warning for that, and yes, it should be.
I'm appalled that this wasn't taken care of 20 years ago. It seems like such low-hanging fruit.
I assume it means globals, which is significantly less trivial. Any SSA-based compiler, which GCC has been for years and years, trivially does this for locals.
Re:GCC 5.2 released
by greglindahl on Thursday July 16, 2015 @12:46PM
(#9898330)
This is a standard compiler feature, yes -- lots of real code out there has a lot of dead writes, such as debugging code that has been only partly removed or disabled. Historically, it's been a significant win for some of the SPECcpu benchmarks.
It's standard to remove local variables that are write-only, but globals aren't always defined to be unused even when you want them to be. If you're building a shared library and you exported the symbol, it has to leave it in as part of the API.
Link-time optimization can delete a lot more stuff when you're building a program directly, since it only has to keep main()… as long as you didn't go and use things like function pointers.
This is one reason I try to use '-fvisibility=hidden' in libraries, because it prevents anything from being part of the API unless you go back and specifically export it.
Historically, it's been a significant win for some of the SPECcpu benchmarks.
But doesn't it mean that you're not really executing the full benchmark then?
Re:GCC 5.2 released
by greglindahl on Thursday July 16, 2015 @04:40PM
(#9899760)
No, because no one ever reads the dead data. These are not microbenchmarks that get broken by optimizations like this; SPECcpu programs have answers, and the goal is to output the answer. The answer is tested. Anything you can delete from the program is fair game.
[deleted]
Those pointers always need to be defined as volatile anyway
[deleted]
That's probably something one should keep in mind when writing micro-benchmarks.