Again, you fail to differentiate between the optimization and code gen stages of compilation. I read the settlement as meaning a failure to optimize.
Really simple to test though: take a piece of code, manually insert an SSE instruction, and compile with all optimizations disabled. Then compile with optmizations enabled.
If what you argue is true, then with no optimizations, the only code path would be the SSE instruction, and the app would instantly crash within the CPU dispatcher.
You didn't do your home work since last time.
Agner already did exactly that, it doesn't work. I can tell your a HLL guy.
The Intel Compiler compiles any code multiple times, then inserts it's dispatcher into the front of that code. When you execute that code the dispatcher will check your CPUID / VendorID and use that to determine which code path to use, this is done at run time. No matter what you do to your code the compiler will always generate multiple paths and one of those paths will include i386 / x86 instructions only (no SSE / MMX / FMA / AVX). You can manually insert a SIMD instruction using ASM and the compiler will just replace it with a i386 equivalent on the generic i386 path. Thus even if the software developer manually inserted ASM into every aspect of their code, the Intel compiler will just override that during compile time. You will get two sets of code, one with your own optimizations and one with the generic i386 optimizations.
Thus Intel's compiler was determined by the FTC to be a defective product and inserting unwanted artificial performance impairments into the products of it's customers. AMD and Intel were told to settle their disagreements or the civilian courts would do it for them, thus the CLA was made and Intel agreed to not introduce artificial performance impairments into it's compiler for AMD cpus. The FTC then separately told Intel they couldn't do that to ~anyone~ and to stop using unethical business practices (referring to the OEM deals), if Intel didn't fix their issue the FTC would take it to the justice department.
This was all with the older Compiler prior to 2010, the one made after 2010 instead use's SSE2 in it's generic instruction path. Meaning if you hand coded SSE4.2 ASM and compiled it, the Intel Compiler will generate two instruction sets, one with SSE2 only (recoding your SSE4.2 optimizations) and one with the SSE4.2 capable path. You would have to patch the binary afterwards to remove the VendorID check from the dispatcher. Or you can force the compiler to only generate one code path and remove the dispatcher completely, this introduces the issue where you've limited the compatibility of the code similar to what GCC and MSVC have to deal with.
*Note*
The Intel Compiler actually generates more then one code path, I restricted the statement to the two that mattered the most, the generic i386 one and the optimized one.
Any SIMD operate can be done by a sequence of integer operations instead. The SIMD instruction is vastly more efficient as it allows those operations to be done in a few cycles vs the 40~50+ cycles. Thus it is easy for a compiler to do code substitution, in fact every modern compiler does this anyway in an attempt to optimize your data and instruction segments.