On Tue, 22 Sep 2026 20:45:28 GMT, Vladimir Ivanov <[email protected]> wrote:
>> 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. Understood. Let me address `NotV(NotV M) => M` first. I’ll create a separate PR for it. Thank you. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/31333#discussion_r4078138914
