RFR: 8345169: Implement JEP XXX: Remove the 32-bit x86 Port

[David Holmes]

On Thu, 5 Dec 2024 08:26:10 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> **NOTE: This is work-in-progress draft for interested parties. The JEP is not even submitted, let alone targeted.**
> 
> My plan is to to get this done in a quiet time in mainline to limit the ongoing conflicts with mainline. Feel free to comment in this PR, if you see something ahead of time. These comments might adjust the trajectory we take to implement this removal and/or allows us submit and work out more RFEs ahead of this removal. I plan to re-open a clean PR after this preliminary PR is done, maybe after the round of preliminary reviews.
> 
> This removes the 32-bit x86 port and does a deeper cleaning in Hotspot. The following paragraphs describe what and why was being done.
> 
> Easy stuff first: all files named `*_x86_32` are gone. Those are only built when build system knows we are compiling for x86_32. There is therefore no impact on x86_64.
> 
> The code under `!LP64`, `!AMD64` and `IA32` is removed in `x86`-specific files. There is quite a bit of the code, especially around `Assembler` and `MacroAssembler`. I think these removals make the whole thing cleaner. The downside is that some of the `MacroAssembler::*ptr` functions that were used to select the "machine pointer" instructions either from x86_64 or x86_32 are now exclusively for x86_64. I don't think we want to rewrite `*ptr` -> `*q` at this point. I think we gradually morph the code base to use `*q`-flavored methods in new code.
> 
> x86_32 is the only platform that has special cases for x87 FPU.
> 
> C1 even implements the whole separate thing to deal with x87 FPU: the parts of regalloc treat it specially, there is `FpuStackSim`, there is `VerifyFPU` family of flags, etc. There are also peculiarities with FP conversions that use FPU, that's why x86_32 used to have template interpreter stubs for FP conversion methods. None of that is needed anymore without x86_32. This cleans up some arch-specific code as well.
> 
> Both C1 and C2 implement the workarounds for non-IEEE compliant rounding of x87 FPU. After x86_32 is gone, these are not needed anymore. This removes some C2 nodes, removes the rounding instructions in C1.
> 
> x86_64 is baselined on SSE2+, the VM would not even start if SSE2 is not supported. Most of the checks that we have for `UseSSE < 2` are for the benefit of x86_32. Because of this I folded redundant `UseSSE` checks around Hotspot.
> 
> The one thing I _deliberately_ avoided doing is merging `x86.ad` and `x86_64.ad`. It would likely introduce uncomfortable amount of conflicts with pending work in mainli...

src/hotspot/share/interpreter/abstractInterpreter.cpp line 137:

> 135:       case vmIntrinsics::_floatToRawIntBits: return java_lang_Float_floatToRawIntBits;
> 136:       case vmIntrinsics::_longBitsToDouble:  return java_lang_Double_longBitsToDouble;
> 137:       case vmIntrinsics::_doubleToRawLongBits: return java_lang_Double_doubleToRawLongBits;

Why are these intrinsics for the Java methods disappearing?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22567#discussion_r1904957718