Couldn't that also potentially break some logic branch through the chip where the app is expected to be running on a GenuineIntel processor? I'm not well versed in this.
Not likely. AMD processors are very carefully designed to correctly execute code, even if it just assumes GenuineIntel and never even checks.
If code is dumb enough to try to use something low-level (let's use Bull Mountain RDRAND as an example) without checking for that specific feature bit, then it obviously is the code that is broken, leading to an illegal operation and it gets killed. That's not the CPU's fault.
Intel and AMD CPU manuals both pound in the point, too. In the sections on these advanced features they always insist that you check the feature bit first.
Your mention of RDRAND is a great point and made me think about just how many differences there are between different models of CPUs from the same vendor. I assume the differences between different Intel CPUs vastly outweigh the differences between similar Intel and AMD CPUs.
Possibly, as Intel's compiler uses dynamic code-path selection based on the processor.
But more likely, it would mean slower code execution, as the code path wouldn't be optimised for AMD:
i.e. if the processor check thinks it's running an i7 Sandy Bridge, with an SSE float divide latency of 11, but the AMD chip has a latency of 23, so the unrolled loop that worked well for the i7 doesn't work at all for the AMD chip.
Except it turns out not to work that way - most of the optimisations turn out to be general ones, and some of the non-optimised code paths AMD gets for stuff like string copying are slower than a naive implementation. (Actually, Intel wound up having to fudge the CPUID result on their newer processors for this reason. Otherwise binaries compiled on their older compilers would detect an unrecognised chip and run the slow path - including some of the benchmarkers reviewers would use to compare the two!)
