[PATCH] D28137: [Devirtualization] MemDep returns non-local !invariant.group dependencies

[Daniel Berlin via llvm-commits]

>
>
>
> I understand your argument that after optimizing to a fixed point, we
> should get the same result.  The problem is that the *order* of iteration
> will differ.  This can mean differences in naming, memory allocation
> patterns, or even output (I don't believe GVNPRE actually iterates to a
> fixed point.)
>

GVN + PRE these days does iterate to a fixpoint, but it also gives up if it
doesn't converge quickly.



>
> > I can continue looping and either try hard to find local dependency or
> 'the best' non-local dependency (which probably won't be found because GVN
> will already remove it)
> >  and return it, or even collect list of all non local dependencies.
>
> The key point is that we should return a consistent result, regardless of
> which query path we see.  Returning the most dominating non-local would be
> one reasonable scheme.
>
> > I am also not sure if I understand what 'the best' non local dependency
> means.
>
> Don't get too caught up on "best" here.  The ordering point above is the
> primary concern.  A secondary concern is reducing the number of iterations
> required to reach the fixed point.  Why do multiple full scans if we can
> bypass all but one with a small amount of extra work?  Particularly work
> that we know only happens when we have found a useful result and are just
> trying to find a better one?  (i.e. we're not burning time when we're not
> making progress.)
>


+1 to this however. Truthfully, we can always make invariant group loads
faster. We could, for example, link them together, etc.

This is not the thing that is hard to speed up :)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20161230/09c1ab2b/attachment.html>