https://gcc.gnu.org/bugzilla/show_bug.cgi?id=126984
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Last reconfirmed| |2026-08-24
Ever confirmed|0 |1
Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot
gnu.org
Status|UNCONFIRMED |ASSIGNED
--- Comment #3 from Richard Biener <rguenth at gcc dot gnu.org> ---
Mine. So the fundamental issue is that we can have a SLP subgraph that looks
like a complex expression but does not map to any actual scalar lane due to
reassociation during SLP build:
t.c:4:6: note: node 0x524dc00 (refcnt=2) vector([2,2]) double
t.c:4:6: note: op: VEC_PERM_EXPR
t.c:4:6: note: { }
t.c:4:6: note: lane permutation { 0[0] 1[1] }
t.c:4:6: note: children 0x524db50 0x524df70
t.c:4:6: note: node 0x524db50 (refcnt=1) vector([2,2]) double
t.c:4:6: note: op template: _18 = _15 + _17;
t.c:4:6: note: { }
t.c:4:6: note: children 0x524d260 0x524d520
t.c:4:6: note: node 0x524df70 (refcnt=2) vector([2,2]) double
t.c:4:6: note: op: VEC_PERM_EXPR
t.c:4:6: note: { }
t.c:4:6: note: lane permutation { 0[1] 0[0] }
t.c:4:6: note: children 0x524d730
t.c:4:6: note: node 0x524d730 (refcnt=2) vector([2,2]) double
t.c:4:6: note: op template: _19 = j_39 * i_40(D);
t.c:4:6: note: stmt 0 _19 = j_39 * i_40(D);
t.c:4:6: note: stmt 1 _31 = k_38 * i_40(D);
t.c:4:6: note: children 0x524d7e0 0x524d890
t.c:4:6: note: node 0x524d260 (refcnt=2) vector([2,2]) double
t.c:4:6: note: op template: _17 = d.8_16 * k_38;
t.c:4:6: note: stmt 0 _17 = d.8_16 * k_38;
t.c:4:6: note: stmt 1 _29 = d.15_28 * j_39;
t.c:4:6: note: children 0x524d310 0x524d3c0
t.c:4:6: note: node 0x524d520 (refcnt=2) vector([2,2]) double
t.c:4:6: note: op template: _11 = b.4_9 * f.5_10;
t.c:4:6: note: stmt 0 _11 = b.4_9 * f.5_10;
t.c:4:6: note: stmt 1 _23 = b.11_21 * e.12_22;
t.c:4:6: note: children 0x524d5d0 0x524d680
and we need the scalar stmt for "reasons" (creating a fake "scalar" pattern
stmt).
It would be best to not have to second-guess a representative "operation"
at this point since we for sure matched adds/subs/mults before. So
complex_pattern should have a m_representative member. complex patterns
are quite a maze and not really my area of expertise.
It's also quite ugly that we scrap m_node in complex_mul_pattern::build
and then call it with garbage (still VEC_PERM, but adjusted children!).
That parent should know a good representative as well, but we can't
pass it to complex_pattern::build because that's an overload, not a
"helper" it seems?! But maybe it is one.
