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

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20170415/fadca328/attachment.html>

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
>