Comment by mike_hock
14 hours ago
Uh ... working around this in each and every piece of software sounds like a non-starter? Intel should be on the hook to fix this.
14 hours ago
Uh ... working around this in each and every piece of software sounds like a non-starter? Intel should be on the hook to fix this.
Use of the "h" register slices (bits 8..15) by compilers is thankfully pretty rare -- otherwise this would have been noticed much sooner!
Agner Fog's optimization guide says "Any use of the high 8-bit registers AH, BH, CH, DH should be avoided because it can cause false dependences and less efficient code."
Use of the "h" register slices (bits 8..15) by compilers is thankfully pretty rare
That's unfortunate, because it's precisely why things like this will keep happening.
Agner Fog's optimization guide says "Any use of the high 8-bit registers AH, BH, CH, DH should be avoided because it can cause false dependences and less efficient code."
The sad vicious cycle of compilers not exercising the hardware, and then the hardware designers not paying attention. Using the high 8-bit registers and "implicitly merging" them is one of the ways to reduce the number of instructions and thus improve size optimisation.
> That's unfortunate, because it's precisely why things like this will keep happening.
I have the opposite opinion. Its use being rare means CPU designers have less need to optimize for that rare case, and hardware optimizations are precisely where these kinds of issues tend to pop up.
And high 8-bit registers are a x86-specific feature, other CPU families don't have it. So that special case being less optimized (or even pessimized) is not much of a loss.
1 reply →
> The sad vicious cycle of compilers not exercising the hardware
There could theoretically be instruction selection passes that are biased toward rare instructions, specialized for fuzzing hardware, I'm surprised Intel doesn't already do that.