On Tue, 28 Apr 2026 21:37:14 GMT, Vladimir Ivanov <[email protected]> wrote:
>> Well, IMO truncation is redundant here. As it is shaped now, `Replicate` >> implicitly performs truncation. Subword types are erased to ints in >> bytecodes, but `Replicate` consumes raw subword values and is expected to >> truncate it when populating a vector. So, when it comes to `Replicate` node >> elimination scenario, I don't see a difference between `Replicate >> INP1`/`Replicate INP2` and `Replicate (ScalarOp INP1 INP2)`. In both cases >> the scalar is not guaranteed to abide to subword bounds. If there's no >> explicit truncation in the former case, what's the point in explicitly >> truncating the result of scalar operation? > > If there's a scenario when `Replicate` is bypassed, it has to take into > account the effects of truncation the node implicitly performs. I'd prefer to > see truncation made explicit and make `Replicate` require its input to be > within bounds, then match corresponding IR tree. But that's something for a > separate RFE. Thanks @iwanowww , originally I banked on the implicit truncation semantics of Replicate https://github.com/openjdk/jdk/pull/25617#discussion_r2851743785 Current truncation IR does not limit the bounds of truncated result using CastIINode, I have removed the explicit truncation logic from this PR and leave it for future RFE if there is a need/consumer of new cleated scalar IR which requires explicit truncation. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25617#discussion_r3159135687
