[llvm-dev] Status of the devirtualization in LLVM/Clang (original) (raw)
Piotr Padlewski via llvm-dev llvm-dev at lists.llvm.org
Sat Apr 15 06:02:38 PDT 2017
- Previous message: [llvm-dev] vector element type for an llvm_anyvector_ty in tablegen?
- Next message: [llvm-dev] About TableGen RangeList
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
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)
- 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.
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
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>
- Previous message: [llvm-dev] vector element type for an llvm_anyvector_ty in tablegen?
- Next message: [llvm-dev] About TableGen RangeList
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]