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

[Vladimir Kozlov]

On Thu, 27 Mar 2025 10:18:24 GMT, Aleksey Shipilev <shade 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`
>  - [ ] 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()`

src/hotspot/share/c1/c1_LinearScan.cpp line 2662:

> 2660: 
> 2661:   } else if (opr->is_single_fpu()) {
> 2662: #if defined(AMD64)

Which platform uses this code? May be check #if for it.

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

PR Comment: https://git.openjdk.org/jdk/pull/24274#issuecomment-2758680360
PR Review Comment: https://git.openjdk.org/jdk/pull/24274#discussion_r2017073229