On Mon, 8 Jun 2026 02:07:32 GMT, Xiaohong Gong <[email protected]> wrote:
>> @XiaohongGong @dean-long What's your opinion here? Ok, or a potential risk >> in the future? > > I left a similar comment above > https://github.com/openjdk/jdk/pull/28002#discussion_r3115506353. I think it > would be better if we could handle such unsupported types in > `match_rule_supported_vector` or `arch_supports_vector`. Although that might > need changes on all vector supported backends, it deserves the effort if that > is the right direction. Hi @XiaohongGong , Take inline_vector_compare as an example. The lane type passed from the Java side is LT_FLOAT16, but match_rule_supported_vector operates on the vector IR opcode, the basic type (which for Float16 is short), and num_elem. So a Float16 compare would be matched as Op_VectorMaskCmp with elem_bt=short and collide with the existing short-integer VectorMaskCmpNode used by ShortVector — giving wrong FP semantics. We would need a distinct Float16 compare IR (as we already did for the other supported vector Float16 ops) before this can be guarded purely by match_rule_supported_vector. That is why, for now, suppressing intrinsification based on lane type is the clean approach; in subsequent patches we can drop the is_unsupported_lane_type checks one by one and rely on match_rule_supported_vector with the new opcodes, which will also guard platforms lacking support. This PR mainly adds the Java-side support and enables intrinsification only for operations that already have auto-vectorization support. Let me know if this looks reasonable. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28002#discussion_r3370878943
