On Fri, 5 Jun 2026 13:24:39 GMT, Jatin Bhateja <[email protected]> wrote:
>> 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 @jatin-bhateja Do you even need `is_unsupported_lane_type`, if `match_rule_supported_vector` should already cover all concrete operations? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28002#discussion_r3362944134
