I have a team that regularly generates savings of XX% of the entire datacenter CPU cycles of a very large fleet through better compiler optimization (that pretty much never breaks any of our programs. In fact, we break them more through almost anything other than better optimization. Shocking, i know, but you can test this stuff really well it turns out, and write sanitizers to find behavior you wouldn't discover at compile time and ...)

I know at least another 100 large companies where the cost savings of doing this kind of thing also totals in the tens to hundreds of millions, per year.

and that's just the normal X% a year, not the "we put a team of experts targeting your use case and they got you 100x" type of savings.

So yeah, there are people for whom this matters ... a lot, and dismissing them casually is not a great idea :)

Truthfully, IME, compiler-optimization induced bugs are so infrequent compared to normal you-wrote-really-wrong code bugs that IMHO it's missing the forest for the trees. (now, maybe people suck more at tracking them down, but ...)

Heck, I had once screwed up some code in GCC that caused it to essentially remove random stores and loads from the program being compiled. It only caused one visible failure across a bunch of real world apps that had serious validation suites.

From reading hacker news, you'd get the idea compiler optimizations follows your code down alleyways to mug it. In truth, people are so busy overflowing buffers and whatnot that we are lucky if we can break their code due to optimizing.