On Tue, 22 Sep 2026 13:40:24 GMT, Eric Fang <[email protected]> wrote:
>> src/hotspot/share/opto/vectornode.cpp line 2919: >> >>> 2917: >>> 2918: // (VectorBlend A B (XorV/XorVMask M -1)) => (VectorBlend B A M) >>> 2919: Node* uncasted_mask = uncast_mask(mask); >> >> A simpler alternative is to detect negated mask shape and swap arguments >> along with double negating the mask: >> >> VectorBlend A B (NotV M) ==> VectorBlend B A (NotV (NotV M)) ==> VectorBlend >> B A M > > Hi @iwanowww thanks for your review! Your suggestion makes sense to me. > However, after some trials, I do not see a clear simplification compared with > the current approach. I have two questions—could you help clarify them? > > 1. The optimization `NotV(NotV M) => M` has not been implemented yet. Should > we open a separate PR to add that optimization first, or should we just > include it in this PR? > > 2. If we convert `VectorBlend A B (NotV M) => VectorBlend B A (NotV (NotV > M))`, then this optimization will depend on `NotV(NotV M) => M`. That means > the two optimizations would not be well decoupled, which does not seem ideal > from a design perspective. Is your concern that the two optimizations may > share some code? If so, perhaps extracting a helper function would be > sufficient. What do you think? Nice discovery! I was under the impression that `NotV(NotV M) => M` is already there while browsing the code, but didn't verify it's already there. > The optimization NotV(NotV M) => M has not been implemented yet. Should we > open a separate PR to add that optimization first, or should we just include > it in this PR? Separate PR would be cleaner, but I'm also fine with covering it as part of this PR. > Is your concern that the two optimizations may share some code? If so, > perhaps extracting a helper function would be sufficient. What do you think? IMO relying on `NotV(NotV M) => M` is cleaner both from implementation and design perspectives. Relying on IR normalization provided by GVN is the recommended practice and it is the primary tool to fight combinatorial explosion of cases to support. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/31333#discussion_r4076313408
