> I like it when the code I specify is the code that's generated

But you aren't specifying it!

You're asking me to follow extra constraints that you haven't written down and we haven't agreed. Don't you think it's unreasonable when you say it out loud like that?

If you want extra constraints on top of what is already agreed in the spec then we can do that, but you have to ask for it and you have to bring me a workable spec. You want me to 'intuit' but really you want me to read your mind and follow a lot of unwritten rules!

I think we have a fundamental difference on what a compiler should do. I want the compiler to take my exact instructions and generate the best machine code it can, that follows those exact instructions. You want to rewrite my program to be more optimal. The tension here is that, even though I'm sure you can do that, I have to debug the result, and the result I have to debug is now stripped of symbols and super hard to relate back to my original source code. So ok, I am only adding one constraint but it's a big one: don't ever change the line-by-line meaning of my source code. If I wrote a line of code I intended for it to be executed, I don't want my memsets removed or my atomics collapsed, not because you can't do it, but because I need to debug it. I don't think taking advantage of undefined behavior to create optimizations is useful because being wrong 10% faster isn't really that useful. And I think optimizations like removing memsets are a really bad idea; not only does it potentially make peoples data insecure but the only people that are ever going to find a bug like that are people looking for vulnerabilities.

And frankly, here's the thing: I don't care that much about most of your optimizations. If I'm making my code fast, what I'm fretting about is designing my data structures to fit in cache, or using SIMD instructions, or offloading work to the GPU or other coprocessors. Screwing with the meaning of my code just makes my life harder.

But the meaning of your program is not being changed or screwed with. The optimised version implements the same meaning as your original program.

The problem is you don't understand the meaning of what you've written. You think the language has extra meaning that it doesn't. You can already get the meaning you want through existing constructs like volatile and yield and memset_s.

> The problem is you don't understand the meaning of what you've written.

This is the problem with the attitude of compiler writers. Of course there are bugs. Nobody perfect. Pobodys nerfect? If I accidentally left a sign overflow in the code, or something of that nature, I think any (human) reading the code would understand what I meant, but the compiler is like "'Lets get weird!'". Yes I CAN get the meaning through the existing construct. That, however, is not my point. I am perfectly skilled and capable of doing this. What I'm questioning is why tool vendors think it's useful or practical to take advantage of users mistakes. I'd rather have a diagnostic of "why are you adding these numbers multiple times?" then have the compiler silently rewrite something I did on purpose.

I'm not writing this in the abstract, I'm writing this because things like this have hurt me in the past. It's super annoying. I don't care about your optimization to make things five percent faster if I spend three days debugging why the release build crashes if the window is full screen, but the debug build runs fine 100% of the time. The code has a bug, I own this, but I don't see how the attitude of "if your code has a bug, we will turn it into fucking dragons" is even remotely useful. Usually it's not even my code I'm fixing, it's someone elses. I just want people to stop breaking things to meet a dumb benchmark.

It sounds like you're railing against optimising based on undefined behaviour. That's a separate thing - that's not what's being discussed in this article or thread - this is all well-defined behaviour.

> I want the compiler to take my exact instructions and generate the best machine code it can, that follows those exact instructions.

Two problems.

1. Your definition of "exact" is not exact. It is exact in your mind, but it isn't going to be precisely the same across all developers and compiler authors cannot reasonably develop hard requirements from this. This is especially true when targeting different machines. Operations on a uin64_t aren't going to look the same on a 32 bit machine, for example.

2. Attempting to do this makes your programs slow as hell. You can claim that compiler optimizations don't matter... but you are free to deploy debug builds if you really think this. C and C++ especially aim to provide a sort of ambient performance where everything is fast rather than just providing speed for hot loops. People complain nearly daily about modern applications being slow and then turn around and say we should throw away decades of compiler optimizations.

I think you're severely underestimating how much slower everything would be if compilers weren't allowed to optimize anymore.

Here's where I start when I'm optimizing things:

- Does my data fit in cache

- Can I make it fit in cache?

- Have I packed my memory efficiently?

- Am I using the right algorithm?

"Can the compiler inline this" is like 5000 on my list of things I care about. Compiler optimizations are mostly only useful to people who werent paying attention in the first place.

> "Can the compiler inline this" is like 5000 on my list of things I care about. Compiler optimizations are mostly only useful to people who werent paying attention in the first place.

Okay, you're definitely severely underestimating how much slower everything would be if compilers weren't allowed to optimize anymore.

Yeah. For somebody who really cares a lot about cache misses he sure doesn't seem to be concerned about basic things like leaving virtual function calls in place.

> I build things for a living and I like it when the code I specify is the code that's generated.

Okay, then specify -O0 and enjoy your dumpster fire performance.

-O0 doesn't necessarily change this. After all, optimizations aren't allowed to violate the spec (if they do, they're buggy). So any code that can be output by an optimizing compiler could (in principle) be output by a non-optimizing compiler.

To be fair, it's usually like 5% slower. But I also don't usually have control over the flags if I'm writing a library.

I’d be curious to know what benchmarks you’re using on which O0 is only 5% slower. I suspect your program must be almost entirely IO-bound, if this is the case. In that case, Python, Ruby, or shell probably wouldn’t be much slower either.

Writing games, I've rarely seen the optimizer do anything of substantial use.