RFR: 8351156: C1: Remove FPU stack support after 32-bit x86 removal

[Aleksey Shipilev]

On Thu, 27 Mar 2025 16:35:01 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> C1 has the 32-bit x86 specific code that supports x87 FPU stack allocations. With 32-bit x86 port removed, we can clean up those parts. 64-bit x86 does not need x87 FPU, since it is baselined on SSE2 and using XMM registers instead.
>> 
>> There are lots of deeper cleanups possible, this PR focuses on removing the x87 FPU allocation/uses in C1. Note current C1 nomenclature is confusing. On all arches, "FPU" means floating-point _registers_. That is _except_ on x86, where "FPU" means x87 FPU stack, and "XMM" means floating-point registers. This is why we only touch "FPU" code on other architectures only in a light manner. After all 32-bit x86 cleanups land, we might consider renaming "XMM" -> "FPU" in x86 C1 to match the common nomenclature.
>> 
>> Brief tour of changes:
>>  - FPU stack simulator is not needed anymore, so I removed it and the related infrastructure
>>  - Lots of 32-bit specific paths that touch x87 FPU registers are pruned
>>  - Related LIR nodes like `lir_fxch`, `lir_fld`, `lir_fpop_raw` are pruned
>>  - Simplified the API that is no longer needed, e.g. dropping `pop_fpu_stack`
>> 
>> This PR would likely conflict with some in-flight cleanups, so it would require merges later. Take a look meanwhile.
>> 
>> Additional testing:
>>  - [x] Linux x86_64 server fastdebug, `tier1`
>>  - [x] Linux x86_64 server fastdebug, `tier1` + `-XX:TieredStopAtLevel=1`
>>  - [x] Linux x86_64 server fastdebug, `all`
>>  - [x] Linux x86_64 server fastdebug, `all` + `-XX:TieredStopAtLevel=1`
>
>> On all arches, "FPU" means floating-point registers.
> 
> Which is wrong I think. It should be "FPR". May be file RFE to rename `LIR_Opr::is_*_fpu()` methods to `LIR_Opr::is_*_fpr()`

Are you still good with this, @vnkozlov? I would like to integrate it sooner to unblock some dependent cleanup work.

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

PR Comment: https://git.openjdk.org/jdk/pull/24274#issuecomment-2761826218