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. ------------- PR Comment: https://git.openjdk.org/jdk/pull/31333#issuecomment-4923140088
