<div dir="ltr">Hi folks,<div>I wanted to share a status on how the devirtualization is doing since I presented it on US LLVM Dev Meeting  (<a href="http://llvm.org/devmtg/2016-11/#talk6" target="_blank">http://llvm.org/devmtg/2016-<wbr>11/#talk6</a>, short summary as a blogpost</div><div>can be found here <a href="http://blog.llvm.org/2017/03/devirtualization-in-llvm-and-clang.html" target="_blank">http://blog.llvm.org/<wbr>2017/03/devirtualization-in-<wbr>llvm-and-clang.html</a>)</div><div><br></div><div>1. Skipping the barrier:</div><div>One of the problems with the invariant.group.barrier was stopping current optimizations from happening, like:</div><div>- figuring out load value through the barrier</div><div>- DSE through the barrier</div><div><br></div><div>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 </div><div>mustalias it's argument. We also needed to mark the barrier with right attributes. Here are soma patches:</div><div><br></div><div>Accepted:</div><div><a href="https://reviews.llvm.org/D31581" target="_blank">https://reviews.llvm.org/<wbr>D31581</a> - DSE through the barrier<br></div><div><a href="https://reviews.llvm.org/D31531" target="_blank">https://reviews.llvm.org/<wbr>D31531</a> - Remove readnone from invariant.group.barrier<br></div><div><br></div><div>Need review:</div><div><a href="https://reviews.llvm.org/D31585" target="_blank">https://reviews.llvm.org/<wbr>D31585</a> - Handle invariant.group.barrier in BasicAA</div><div><a href="https://reviews.llvm.org/D32006" target="_blank">https://reviews.llvm.org/<wbr>D32006</a> - Mark invariant.group.barrier as inaccessiblememonly<br></div><div><a href="https://reviews.llvm.org/D31994" target="_blank">https://reviews.llvm.org/<wbr>D31994</a> - Simplify idempotent invariant.group.barriers<br></div><div><br></div><div>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, </div><div>and all passed (there were around 15 failing before that), so I am really happy about this.</div><div><br></div><div>2. Hoisting invariant.group loads from Loops:</div><div>I wanted to hoist vtable loads from loops, but there is a big problem with LICM: it always drops invariant.group metadata. </div><div>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 <a href="https://reviews.llvm.org/D18738">https://reviews.llvm.org/D18738</a></div><div><br></div><div>3. Changes in clang:</div><div><a href="https://reviews.llvm.org/D31830">https://reviews.llvm.org/D31830</a> - Emit invariant.group.barrier when using union field<br></div><div>Other things I want to work on right now is:</div><div>- emitting barriers for pointers comparison</div><div>- emitting barrier for pointer casts, when dynamic information is lost</div><div>- emitting invariant.group md with empty nodes</div><div>- emitting vtable definition when all of virtual inline functions has been emitted.</div><div><br></div><div><br></div><div>Any feedback will be appreciated!</div><div><br></div><div>Piotr</div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div></div>