4 ms·

I'm appalled that this wasn't taken care of 20 years ago. It seems like such low-hanging fruit.

• greglindahl 11y ago
  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.
  • anon4 11y ago
    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?
    • greglindahl 11y ago
      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.
  • astrange 11y ago
    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.
• pcwalton 11y ago
  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.