Re:GCC 5.2 released
by spacehome on Thursday July 16, 2015 @11:58AM
(#9897993)
I'm appalled that this wasn't taken care of 20 years ago. It seems like such low-hanging fruit.
[ Parent
| on HN ]
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.