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

[Piotr Padlewski via llvm-commits]

2016-12-30 22:22 GMT+01:00 Daniel Berlin <dberlin at dberlin.org>:

>
>>
>> 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 :)
>
>
> That's true, but this is something I would prefer to do in MemSSA :)
AFAIK !invariant.group is only emited with -fstrict-vtable-pointers in
clang, and I never heard any other frontend using it. Because
-fstrict-vtable-pointers is still not default, then this work is more of an
experiment. Before turning it to default there are a couple of other
problems (like skipping barriers etc), that I would not like to implement
in MemDep, and instead do it in MemSSE.
But it would be nice to say that we did milestone in devirtualization for
clang-4.0.

Piotr

PS: consider sending replies in phabricator, because email replies
sometimes doesn't appear there (like this one)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20161230/c3499e3e/attachment.html>