<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Wed, May 4, 2016 at 3:02 PM, Peter Collingbourne <span dir="ltr"><<a href="mailto:peter@pcc.me.uk" target="_blank">peter@pcc.me.uk</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hi all,<div><br></div><div>I wanted to make this proposal to extend ThinLTO to allow a bitcode module to embed another bitcode module containing summary information. The purpose of doing so is to support CFI and  whole-program devirtualization optimizations under ThinLTO.</div><div><br></div><div>Overview</div><div><br></div><div>The CFI and whole-program devirtualization optimizations work by transforming vtables according to the class hierarchy. For example, if a class A has two derived classes B and C, CFI will lay out the vtables for A, B and C consecutively, so that clients can check that a vtable refers to a derived class of A by performing arithmetic on the virtual function pointer. For more details, see [1].</div><div><br></div><div>Both CFI and vtable opt rely on bitset metadata [2] in order to know where the address points for the vtables are located. This is currently encoded using module-level metadata.<br></div><div><br></div><div>In order to lay out the vtables correctly, all vtables need to be visible at once. This is the only part of the process that requires full LTO. The rest of the process can just rely on a set of summary metadata that contains information about how to perform CFI checks for a particular class, or how to devirtualize a particular virtual call. This information could be made part of the ThinLTO summary.</div><div><br></div><div>Implementation</div><div><br></div><div>The idea is to allow bitcode to contain embedded summary blobs. For example, in our scenario, the summary bitcode would contain a section with an embedded blob consisting of a bitcode file containing definitions of the vtables defined by that translation unit and the bitset metadata for CFI and vtable opt, and the "top-level" bitcode would contain everything else.</div><div><br></div><div>The mechanism for merging summaries would be to link the embedded summary bitcode files into a single module using the IRMover, with a mechanism very similar to regular LTO. This would move all the necessary vtables and metadata into a single module where they can be processed using the existing LowerBitSets and WholeProgramDevirt passes, which would be extended to export summary metadata. This summary metadata would be copied into the regular summary information, where it can be used by individual ThinLTO backends.</div><div><br></div><div>In the future, we could also consider representing importing summaries as metadata. That would also make the summary loading process very straightforward.</div><div><br></div><div>Alternatives</div><div><br></div><div>1) We could use a native object file, with one section named ".llvmbc" containing the summary module with the vtables and CFI metadata, and another section ".llvmbc.thin" containing "everything else". This would be my preferred option, as it would make things even simpler. For example, the linker could handle the top-level sections as it reads them, and it would allow the individual sections to be extracted (e.g. using objcopy) and inspected by normal tools, such as llvm-as and llvm-dis. The native object format could also be the container for native code; see my earlier proposal [3].</div><div><br></div><div>The implementation in lld is very simple (about 10 lines in my prototype), but I can accept that it may be more difficult in other linkers, so those linkers may want to use bitcode as the top-level format. In that case, we would probably want to go with what I described in "Implementation".</div></div></blockquote><div><br></div><div><br></div><div>Using the native object format for ThinLTO was the originally proposed (flexibility with binutil tools etc).  We have not revisited the issue ever since. As ThinLTO gets more mature and future use cases, maybe it is time to revisit this (more experience gathered).</div><div><br></div><div>David</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><br></div><div>2) We could emit the vtables and CFI metadata directly into the top-level bitcode. However, this would create a need for a mechanism to distinguish vtables from non-vtables for when we link the LTO parts of the module. In order to do this, we could add a new bitcode record type for bitset metadata that could also act as an index for vtables in a similar way to how ThinLTO importing summaries already work. However, this would add even more complexity to the bitcode format, when I feel that we should really be going the other way with a simpler bitcode format.</div><div><br></div><div>Thanks,</div><span class="HOEnZb"><font color="#888888"><div>-- <br><div><div dir="ltr">-- <div>Peter</div><div><br></div><div>[1] <a href="http://clang.llvm.org/docs/ControlFlowIntegrityDesign.html" target="_blank">http://clang.llvm.org/docs/ControlFlowIntegrityDesign.html</a></div><div>[2] <a href="http://llvm.org/docs/BitSets.html" target="_blank">http://llvm.org/docs/BitSets.html</a></div><div>[3] <a href="http://lists.llvm.org/pipermail/llvm-dev/2016-April/098081.html" target="_blank">http://lists.llvm.org/pipermail/llvm-dev/2016-April/098081.html</a></div></div></div>
</div></font></span></div>
</blockquote></div><br></div></div>