The optimal compiler with perfect knowledge theory never really comes true, and it's been around for a long long time. Many years ago some people said that java would be faster than C, because it can optimize based on information learned at run-time, and there was even a microbenchmark or two to prove it (against naive c of course). They also said that Itanium's crazy VLIW architecture would allow compilers to make more efficient use of processor resources than hardware out-of-order instruction schedulers could. It's been a decade since the height of java and Itanium, and the results speak for themselves.

This popcount thing is a great example. All your layers of abstraction didn't save you from a bug in the lowest layer! (Granted, the only result is some inefficiency, and we sacrifice that all the time.) Keep it simple, you can use abstractions but keep them transparent and debugable. Or not. But don't tell me I should use a high level language and trust the compiler and runtime. Never trust...

"you can use abstractions but keep them transparent"

Wouldn't it defeat the purpose of abstraction?

Not all the purposes. Abstractions can still make the complexity more manageable. Linux kernel developers write the vast majority of their code in C but very often inspect the assembly instructions generated by the compiler. Web developers have many templating languages with macro capabilities (or sass for css), but still want the generated html to be basically readable, so they can verify the templating is doing what they want, and they can debug things.

Some people really can and do ignore things below a particular abstraction, but then there are others who must service that layer transition. And not just the original authors of it. If you have an effective web company of more than, perhaps, 30 developers, at least one of them is dealing with server connection state statistics, occasionally problematic internet routes, occasionally problematic switch configuration or hardware (even on an opaque cloud platform). Someone has to deal with it, or else stuff is kinda flaky, and no one seems to know why...

You can convey some of that information to the compiler by using __builtin_unreachable(), e.g.:

  #define ASSUME(x) if(!(x))__builtin_unreachable()

This is compiler-specific, of course, and introduces undefined behavior if the assumption is violated. There's also no guarantee that the compiler will use the information well. But, it's almost guaranteed to not generate any extra code based on it.

Seems like the under-definedness of integer addition would allow the compiler to emit better code, not worse, because it doesn't have to check for overflow.