https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116463
--- Comment #29 from Tamar Christina <tnfchris at gcc dot gnu.org> --- (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?
