https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116463
--- Comment #31 from Richard Biener <rguenth at gcc dot gnu.org> --- (In reply to Tamar Christina from comment #29) > (In reply to Tamar Christina from comment #27) > > > > > > > > We DO already impose any order on them, but the other operand is > > > > oddodd, so > > > > the overall order ends up being oddodd because any known permute > > > > overrides > > > > unknown ones. > > > > > > So what's the desired outcome? I guess PERM_UNKNOWN? I guess it's > > > the "other operand" of an add? What's the (bad) effect of classifying > > > it as ODDODD (optimistically)? > > > > > > > So the question is, can we not follow externals in a constructor to > > > > figure > > > > out if how they are used they all read from the same base and in which > > > > order? > > > > > > I don't see how it makes sense to do this. For the above example, what's > > > the testcase exhibiting this (and on which arch)? > > > > I've been working on a fix from a different angle for this, which also > > covers another GCC 14 regression that went unnoticed. I'll post after > > regressions finish. > > So I've formalized the handling of TOP a bit better. Which gets it to > recognize it again, however, it will be dropped as it's not profitable. > > The reason it's not profitable is the canonicalization issue mentioned > above. This has split the imaginary and real nodes into different > computations. > > So no matter what you do in the SLP tree, the attached digraph won't make > the loads of _5 linear. Are you ok with me trying that Richi? I can't make sense of that graph - the node feeding the store seems to have wrong scalar stmts? What's the testcase for this (and on what arch?). But yes, the loads of *5 won't get linear here, but at least the permute node feeding the complex-add-rot270 can be elided, eventually even making the external _53, b$real_11 match the other with different order (though we don't model that, cost-wise).