On Wed, 11 Nov 2026 09:01:58 GMT, Emanuel Peter <[email protected]> wrote:
>> The test failure on Windows is unrelated to this PR, it's about installing >> MSYS2 on ARM64. > > @erifan Thanks for the explanations. I see that sharing code between scalar > and vector optimizations could be very interesting. > > The question is about the concrete design, naming etc. This discussion goes > beyond what the PR description mentions, and would warrant careful > consideration/prototyping/review. Unfortunately, I'm currently focused on > JDK28 bugs (fixes and reviews). Can you delay this issue to JDK29, when we > may have some more cycles to review such RFEs? > > I would also like to hear @iwanowww @chhagedorn or other more senior > engineers on this issue. > > One thought I just had: Could we split the additional optimization and the > "generic optimization framework" into two RFE's? You can still implement your > vector optimization in a generic way, but restricted to vector files. And > then in a second step do the refactoring, where you demonstrate how we can > use your "generic optimization framework" for both scalar and vector > optimizations. That would allow us to discuss the naming and design in a > proper way, where we can see the final result. An alternative would be to > find existing scalar and vector optimizations where you can already > demonstrate the "generic optimization framework", and then add your new > optimizations in a second RFE. What do you think? @eme64 Thanks. I think your suggestion is reasonable: a framework shared across scalar and vector optimizations should be evaluated with concrete users, and its API, naming, and organization deserve careful review. But the PR has evolved through several rounds of discussion and review, both internally and in the OpenJDK community. @theRealAph and @dean-long helped move the original backend optimization into the C2 middle end, and @merykitty provided detailed feedback on the current shared implementation. Given that history and the testing already done, I am reasonably confident in the current implementation. And since it only affects the two optimizations introduced in this patch, the risk should be relatively low. So I would greatly appreciate it if this PR could still make JDK-28. As @merykitty mentioned, the current implementation already covers two different node forms, VECTOR and PVECTMASK, and extending it to scalar nodes appears straightforward. And to make the framework more concrete, I can prepare a separate prototype patch based on an existing scalar optimization: `(A + B) - B -> A` This optimization currently exists for scalar INT/LONG nodes but not for integral vector nodes. The prototype would move the scalar logic into `GenericOpts` and use the same implementation for INT, LONG, and unpredicated integral vectors. > What do you mean by "restricted to vector files"? @merykitty I think @eme64 means using the traditional approach—implementing it in `vectornode.cpp`, similar to https://github.com/openjdk/jdk/blob/a442c1beaaa49e03f735db12cadb16d4f6b5bebe/src/hotspot/share/opto/vectornode.cpp#L2837 ? ------------- PR Comment: https://git.openjdk.org/jdk/pull/32095#issuecomment-6793169034
