RFR: 8020282: Generated code quality: redundant LEAs in the chained dereferences [v2]
Roberto Castañeda Lozano
rcastanedalo at openjdk.org
Thu Jun 12 13:06:43 UTC 2025
On Wed, 4 Jun 2025 13:22:11 GMT, Manuel Hässig <mhaessig at openjdk.org> wrote:
>> src/hotspot/cpu/x86/peephole_x86_64.cpp line 244:
>>
>>> 242: // the DecodeN. However, after matching the DecodeN is added back as the base for the leaP*,
>>> 243: // which is nessecary if the oop derived by the leaP* gets added to an OopMap, because OopMaps
>>> 244: // cannot contain derived oops with narrow oops as a base.
>>
>> Am I correct to assume that if it is referenced in OopMap (which is side table) it will by referenced by some Safepoint node in graph?
>
> Exactly. This is why I can get away with only checking the usages of the decode.
Is this scenario exercised by any of the new tests? If not, would it be possible to construct an additional test where we verify that the peephole is not applied in this case?
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/25471#discussion_r2142650623
More information about the hotspot-compiler-dev
mailing list