On Wed, Jan 18, 2017 at 2:54 PM, Richard Biener <richard.guent...@gmail.com> wrote: > On Wed, Jan 18, 2017 at 11:10 AM, Martin Liška <mli...@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 >>
