On Wed, 16 Sep 2026 08:13:01 GMT, Guoxiong Li <[email protected]> wrote:
>> Gui Cao has updated the pull request with a new target base due to a merge >> or a rebase. The pull request now contains 26 commits: >> >> - Merge remote-tracking branch 'upstream/master' into JDK-8358959 >> - Update for Axel code review >> - RISC-V: Gate native AtomicAccess Zalasr dispatch on a post-validated flag >> - Code format >> - RISC-V: Zalasr code review followups >> - Apply code review >> - RISC-V: Use Zalasr for the ordered accesses in AtomicAccess >> - Merge remote-tracking branch 'upstream/master' into JDK-8358959 >> - RISC-V: Align C1 volatile load dispatch with AArch64 >> - Merge remote-tracking branch 'upstream/master' into JDK-8358959 >> - ... and 16 more: https://git.openjdk.org/jdk/compare/b0ac803f...bcc84174 > > src/hotspot/cpu/riscv/riscv.ad line 5094: > >> 5092: instruct loadKlass(iRegPNoSp dst, memory mem) >> 5093: %{ >> 5094: predicate(!needs_acquiring_load(n)); > > Now, we don't have a `instruction` rule to match `needs_acquiring_load` is > true. Is it a intentional behavior? Intentional, and it's actually guaranteed by construction rather than just "not currently exercised": `needs_acquiring_load(n)` forwards to `n->as_Load()->is_acquire()`, which just checks the `_mo` field baked into the Load node at construction time. - For ordinary Java field loads (`LoadP`/`LoadN`), `_mo` is set to `MemNode::acquire` in `BarrierSetC2` 's decorator-resolution logic (`barrierSetC2.cpp`) whenever the field being accessed is volatile — that's exactly the path `loadP_volatile`/`loadN_volatile` exist for. - `LoadKlassNode` never goes through that path. Its constructor is private, and the only way to build one is `LoadKlassNode::make()` (`memnode.cpp`), which hardcodes `MemNode::unordered` unconditionally, for both the narrow and wide cases. There's no call path anywhere in the graph that can produce a `LoadKlassNode` with `_mo == acquire`. So `needs_acquiring_load(n)` is structurally always false for a `LoadKlass` node ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/32309#discussion_r4027769288
