https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115060
Bug ID: 115060 Summary: Probable an issue around usage of vect_look_through_possible_promotion in tree-vect-patterns.cc Product: gcc Version: 15.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: fxue at os dot amperecomputing.com Target Milestone: --- The purpose of the function is to peel off type casts to find out root definition for a given value. If patterns are involved, intermediate pattern-defined SSAs would be traversed instead of the originals. A subtlety here is that the root SSA (as the return value) might be the original one, even it has been recognized as a pattern. For example, a = (T1) patt_b; patt_b = (T2) c; // b = ... patt_c = not-a-cast; // c = old_seq Given 'a', the function will return 'c', instead of 'patt_c'. If a caller only does something based on type information of returned SSA, there is no problem. But if caller's pattern recog analysis is to parse definition statement of the SSA, the new pattern statement is bypassed. This tends to be inconsistent with processing logic of the pattern formation pass, which is not quite rational, and seems to be an issue, though does not cause any mistake. Anything that I missed here? Take one code snippet as example: vect_recog_mulhs_pattern () { ... vect_unpromoted_value unprom_rshift_input; tree rshift_input = vect_look_through_possible_promotion (vinfo, gimple_assign_rhs1 (last_stmt), &unprom_rshift_input); ... /* Get the definition of the shift input. */ stmt_vec_info rshift_input_stmt_info = vect_get_internal_def (vinfo, rshift_input); if (!rshift_input_stmt_info) return NULL; gassign *rshift_input_stmt = dyn_cast <gassign *> (rshift_input_stmt_info->stmt); if (!rshift_input_stmt) return NULL; ... if (gimple_assign_rhs_code (rshift_input_stmt) == PLUS_EXPR) // How about if rshift_input_stmt has a pattern replacement? { ... }