Remember, kids: thinking before speaking will never go out of fashion.
An executable built with optimizations that require non-x86 instruction sets won't work on a CPU that doesn't support said instruction sets regardless of who manufactured the CPU. In other words, when it comes to compatibility, what's important is the instruction sets that are implemented in the chip, not who made it.
Not to mention that it's possible to turn off special instruction set optimizations to make the compiler produce pure x86 code.
Remember, kids: thinking before speaking will never go out of fashion.
That sentence was completely pointless, helios. Why did you put it there?
Here was my thinking at the time, roughly translated:
Intel created the compiler. Intel is also the largest manufacturer of CPUs. That said, Intel could easily have implemented undocumented instructions into their chips. Then, they could easily have made their compiler use those instructions indefinitely. The result is code that runs faster but is platform specific. If those instructions were undocumented and the compiler was closed-source, it wouldn't be easy to find out about those instructions... so how would AMD be able to implement them in their processors? QED.
Remember, kids: thinking before speaking will never go out of fashion.
I think quite a lot, thank you very much.
Of course, upon further research, Intel compilers do support certain AMD processors.
More importantly, if your compiler reports that it's producing code for an instruction set A but it's actually producing code for B that's a superset of A, that's a problem for you, because a CPU that's known to support A may fail to run the generated code. That would be like a C++ compiler that actually generates .NET bytecode. Making a compiler that does things it wasn't instructed to do is undesirable.
There are also better ways to do what you proposed. If you know your implementation runs the instructions a, b, and c faster than the equivalent d and e, you can have your compiler generate that, instead. The problem is that a) that behavior is probably documented and that b) it may not hold true for future versions.