On Tue, 7 Jul 2026 08:19:40 GMT, Eric Fang <[email protected]> wrote:
>>> I can extend these tests to all types if you feel it's necessary. >> >> The only one that I think might need some investigation is Float16. Have you >> explored if that type would behave the same way, or maybe there is some work >> required to make it work? It would be absolutely fine to enhance the test as >> a follow up, but now could be a good opportunity to explore what is required >> to make it work. > >> > I can extend these tests to all types if you feel it's necessary. >> >> The only one that I think might need some investigation is Float16. Have you >> explored if that type would behave the same way, or maybe there is some work >> required to make it work? It would be absolutely fine to enhance the test as >> a follow up, but now could be a good opportunity to explore what is required >> to make it work. > > Thanks @galderz. I looked into Float16 specifically. > > These transforms are purely structural — they only inspect the blend nesting > and the mask (all-ones/all-zeros, XorV/XorVMask, nested VectorBlend sharing > the same mask). They don't inspect the lane's BasicType and don't perform any > arithmetic. Since a blend is a pure whole-lane select (M ? Y : X), there's no > rounding/NaN concern, so the optimizations are correct and applicable to > Float16 exactly as they are for int/long/float/double. No code change is > needed here to "make it work" for Float16. > @erifan I gave it a quick glance. Looks reasonable. We could consider > extending the IR tests to more vector element types, if more convenient with > the Template Framework. > > Also: did you already run many runs of > `compiler/vectorapi/VectorExpressionFuzzer.java`? In my experience, it often > finds bugs, but only if you run it 1000x or more. Ok, I'll add more tests for all of vector element types and run the fuzzer test repeatedly ------------- PR Comment: https://git.openjdk.org/jdk/pull/31333#issuecomment-4934012371
