[llvm-dev] [cfe-dev] RFC: Devirtualization v2

[Piotr Padlewski via llvm-dev]

2018-03-20 22:14 GMT+01:00 Reid Kleckner <rnk at google.com>:

> Sounds like it works!
>
> Basically, adding these extra strip.invariant.group calls before pointer
> comparisons breaks the transform that was problematic. Presumably, clang
> would only strip invariant groups from pointers to dynamic types before
> casting them or using them in a comparison, so that the value equivalence
> optimization still works in the general case. The proposal trades value
> equivalence power for more devirtualization power.
>
> If optimizer was able to infer some equivalence of pointers before, it
should be also able to do it right now, and that is thanks to the
strip.invariant.group semantics. Compared to previous proposal, we do not
get any more devirtualization
power (assuming we didn't care about the full correctness) and hopefully we
do not loose any other optimizations. But ofc comparing to the -O2 we
definitelly get more devirtualization :)


> One downside is that it may add many new IR instructions, but I don't see
> how to avoid them, as the whole point is to create distinct Value objects
> for use in the pointer equality comparison.
>
> That is correct, we do get more instructions (especially that the calls to
{strip,launder}.invariant.group usually need to have bitcast to i8* and
back from i8*) and I also don't see how we could avoid them (exept unifying
pointer types which I hope will happen some day), but the good part is that
because of the semantics of strip (especially readnone attribute) the
optimizer should be able to CSE all the calls to strip.invariant.group to
one.


> On Mon, Mar 19, 2018 at 4:31 PM Piotr Padlewski via cfe-dev <
> cfe-dev at lists.llvm.org> wrote:
>
>> Hi folks,
>>
>> here is a link to the proposal that we've been working on lately:
>> https://docs.google.com/document/d/16GVtCpzK8sIHNc2qZz6RN8amICNBt
>> vjWUod2SujZVEo/edit?usp=sharing
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180321/b6f1bc80/attachment.html>