Found this while cleaning up x86_32 code for removal.

In our current code there is a block added by JDK-8076373:
https://github.com/openjdk/jdk/blob/3b21a298c29d88720f6bfb2dc1f3305b6a3db307/src/hotspot/share/compiler/compileBroker.cpp#L1451-L1473

Ostensibly, that block is for x86_32 handling of signalling NaNs -- x87 has a peculiarity with them. But the way current block is coded, it is enabled for X86 wholesale, which also means x86_64! In fact, it is likely even worse on x86_64, because the related "fast" entries are generated only for x86_32:
https://github.com/openjdk/jdk/blob/3b21a298c29d88720f6bfb2dc1f3305b6a3db307/src/hotspot/share/interpreter/templateInterpreterGenerator.cpp#L493-L502

This can be solved by checking IA32 instead of X86.

This seems to only affect the compilation of native methods, while most of the hot code is likely just riding on C2 intrinsics.