On Thu, 25 Jun 2026 12:33:16 GMT, Tobias Hartmann <[email protected]> wrote:
>> Hi, as discussed here, >> https://github.com/openjdk/jdk/pull/31122#discussion_r3456766597 >> >> I think there's a bug here. Although this issue occurs on RISC-V, we can >> see that this spill was automatically inserted by RA; we didn't perform any >> operations manually. >> And maybe the reason of a spill move [c_rarg5|L] [stack:10|L] inserted by RA >> is probably because the registers are under a lot of pressure at this stage. >> I created a new issue to track https://bugs.openjdk.org/browse/JDK-8387252, >> and I'll try to reproduce this bug on other architectures. >> >> >> >> >> --------- >> - [x] I confirm that I make this contribution in accordance with the >> [OpenJDK Interim AI Policy](https://openjdk.org/legal/ai). > > src/hotspot/share/c1/c1_LIRGenerator.cpp line 2397: > >> 2395: // (inside the conditional code), and the stub's continuation >> jump >> 2396: // would skip that spill, leaving the spill slot stale. >> 2397: load_result = new_register(T_OBJECT); > > Shouldn't the `rlock_result` just above in line 2381 do exactly that? I think we need to detect spills in conditional code at compile time. I'm not convinced creating a new virtual register for "load_result" here is correct either. It moves the problem to a different virtual register, one that has a shorter lifetime that "result", but does that guarantee there won't be a spill? We are still setting a register in two different paths that are invisible to C1 LIR. ------------- PR Review Comment: https://git.openjdk.org/valhalla/pull/2579#discussion_r3479540741
