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).

Reply via email to