On Fri, 5 Jun 2026 07:39:42 GMT, Jatin Bhateja <[email protected]> wrote:
>> src/hotspot/share/opto/vectorIntrinsics.cpp line 320:
>>
>>> 318: static bool is_unsupported_lane_type(VectorSupport::LaneType laneType)
>>> {
>>> 319: return laneType == VectorSupport::LaneType::LT_FLOAT16;
>>> 320: }
>>
>> The safer way would have been to invert the condition.
>> Suppose we add yet another lane type. And forget to add it to the
>> `unsupported` list in some platform. And then we get a bug. That would be
>> annoying.
>
> Hi @eme64 , This helper is transient. The plan is is to remove call sites one
> by one as each inline expander gains
> full Float16 support, and to delete the function entirely once Float16
> reaches parity with the other lane types
> @jatin-bhateja And you will manage to do that on all platforms?
Hi @eme64, even today the vector IR emitted by inline expanders is not
uniformly supported across all targets — that gating happens per-backend in
match_rule_supported_vector and match_rule_supported_vector_masked, which is
where unsupported opcode/lane combinations are rejected.
When the is_unsupported_lane_type call sites are lifted in subsequent patches,
that per-backend gate is still in place: any target lacking Float16 IR support
continues to fall back through the same path it uses today for any other
unsupported (opcode, lane type) pair.
So inverting condition would not change the platform-portability picture either
way
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/28002#discussion_r3362919159
