[llvm-dev] [cfe-dev] Status of the devirtualization in LLVM/Clang

[Alexey Salmin via llvm-dev]

Hello Piotr!

Thank you for the update. Unfortunately I'm not familiar with
clang/llvm internals so it's not quite clear for me which particular
devirtualization cases will be solved with upcoming patches. Would it
be possible to see some examples? For instance case [1] doesn't work
with the current trunk, I've added it to the #13227 report [2].
There're more code samples in [2] and also in other reports on
bugs.l.o [3],[4]. Sorry if this is a wrong place to ask.

Alexey

[1] https://godbolt.org/g/TmyZs1
[2] https://bugs.llvm.org/show_bug.cgi?id=13227
[3] https://bugs.llvm.org/show_bug.cgi?id=3100
[4] https://bugs.llvm.org/show_bug.cgi?id=27096

On Sat, Apr 15, 2017 at 4:02 PM, Piotr Padlewski via cfe-dev
<cfe-dev at lists.llvm.org> wrote:
> Hi folks,
> I wanted to share a status on how the devirtualization is doing since I
> presented it on US LLVM Dev Meeting  (http://llvm.org/devmtg/2016-11/#talk6,
> short summary as a blogpost
> can be found here
> http://blog.llvm.org/2017/03/devirtualization-in-llvm-and-clang.html)
>
> 1. Skipping the barrier:
> One of the problems with the invariant.group.barrier was stopping current
> optimizations from happening, like:
> - figuring out load value through the barrier
> - DSE through the barrier
>
> After chatting with Chandler and Hal during Euro LLVM we agreed that this
> can be solved by giving Alias Analysis the knowledge that the pointer
> returned by the barrier
> mustalias it's argument. We also needed to mark the barrier with right
> attributes. Here are soma patches:
>
> Accepted:
> https://reviews.llvm.org/D31581 - DSE through the barrier
> https://reviews.llvm.org/D31531 - Remove readnone from
> invariant.group.barrier
>
> Need review:
> https://reviews.llvm.org/D31585 - Handle invariant.group.barrier in BasicAA
> https://reviews.llvm.org/D32006 - Mark invariant.group.barrier as
> inaccessiblememonly
> https://reviews.llvm.org/D31994 - Simplify idempotent
> invariant.group.barriers
>
> I believe that this solves most (if not all) blocking optimizations
> problems. I even checked how many Clang's tests will fail with
> -fstrict-vtable-pointers set by default,
> and all passed (there were around 15 failing before that), so I am really
> happy about this.
>
> 2. Hoisting invariant.group loads from Loops:
> I wanted to hoist vtable loads from loops, but there is a big problem with
> LICM: it always drops invariant.group metadata.
> For loads that are guaranteed to happen it is probably safe to not discard
> metadata, and for speculative loads we need a new concept of metadata that
> holds globally (unconditionally) - like the one proposed here
> https://reviews.llvm.org/D18738
>
> 3. Changes in clang:
> https://reviews.llvm.org/D31830 - Emit invariant.group.barrier when using
> union field
> Other things I want to work on right now is:
> - emitting barriers for pointers comparison
> - emitting barrier for pointer casts, when dynamic information is lost
> - emitting invariant.group md with empty nodes
> - emitting vtable definition when all of virtual inline functions has been
> emitted.
>
>
> Any feedback will be appreciated!
>
> Piotr
>
>
>
>
>
>
>
>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>