Re: [PATCH] Be careful about combined chain with length == 0 (PR, tree-optimization/70754).

["Bin.Cheng" <amker dot cheng at gmail dot com>]

On Wed, Jan 18, 2017 at 2:54 PM, Richard Biener
<richard.guenther@gmail.com> wrote:
> On Wed, Jan 18, 2017 at 11:10 AM, Martin Liška <mliska@suse.cz> wrote:
>> Hello.
>>
>>
>> Patch can bootstrap on ppc64le-redhat-linux and survives regression tests.
>>
>> Ready to be installed?
>
> I'm not sure.  If we have such zero distance refs in the IL at the
> time pcom runs then not handling
> them will pessimize code-gen for cases where they are part of a larger
> chain.  Esp. I don't like
Do you mean different chains distributed because of MAX_DISTANCE by
"larger chain"?  With the patch, such chain of refs would still be
pred-commoned, just the arithmetic operation not combined, which could
be handled by later DOM?
> another stmt_dominates_stmt_p call and thus rather not handle length
> == 0 at all...
Not handle length == 0 chains at all may be sub-optimal.  As you said,
such chain of refs at the point may simply because previous dom/cse
fail to analyze the references.
>
> We already seem to go great length in associating stuff when combining
> stuff thus isn't this
> maybe an artifact of this association?  Maybe we simply need to sort
> the new chain after
> combining it so the root stmt comes last?
>
> Note that there seems to be only a single length per chain but not all
> refs in a chain need to
> have the same distance.  This means your fix is likely incomplete?
> What prevents the situation
> to arise for distance != 0?
Yes, it's possible for two refs have the same distance in a chain with
length > 0.  But that should not be a problem, because existing uses
are replaced by newly generated PHI variables which always dominate
the uses, right?

Thanks,
bin
>
> Richard.
>
>> Martin
>>