I disagree. I regularly stomp all over the optimizing compiler, and it's not a massive amount of effort. It doesn't come for free though, and requires some upfront planning. The best way to think of it, IMHO is rather than thinking of "beating the compiler", think about working _with_ the compiler to help it do it's job.

I don't always agree with what he says, but Mike Acton has some good words and examples of this. https://www.youtube.com/watch?v=GPpD4BBtA1Y - a youtube talk where he talks about working with the compiler. The slides are at http://www.slideshare.net/cellperformance/gdc15-code-clinic In particular take a look at slide 69 and the few following it for an example of things the compiler can't figure out (for various reasons) that we can help it along with.

That presentation is talking about IR-level optimizations, not codegen-level optimizations. Remember that SPIR-V is an IR, so you are free to manually do IR-level optimizations to your heart's content just as you can on the PS4.

Where IR-level optimizations are concerned, I agree that you can often do in areas like aliasing (where you, the programmer, have more knowledge than a compiler can easily prove). I'm much less convinced that you can beat a compiler at codegen-level optimizations: instruction scheduling, isel, register allocation, etc.

As I said, it should be possible in theory. It boils down to details. I.e. how good the compiler is and how hard is to do better than automatic optimization for given hardware. It's not a uniform yes / no situation.