[PATCH] D28843: IRGen: Start using the WriteThinLTOBitcode pass.

[Peter Collingbourne via Phabricator via cfe-commits]

pcc added inline comments.


================
Comment at: clang/test/CodeGenCXX/type-metadata-thinlto.cpp:2
+// RUN: %clang_cc1 -flto=thin -triple x86_64-unknown-linux -fvisibility hidden -emit-llvm-bc -o %t %s
+// RUN: llvm-modextract -o - -n 1 %t | llvm-dis | FileCheck %s
+
----------------
mehdi_amini wrote:
> pcc wrote:
> > mehdi_amini wrote:
> > > tejohnson wrote:
> > > > Is it the case that now we will always split the module with this change? Should that only be done under CFI options?
> > > Devirtualization may happen whenever you have a hidden virtual table IIUC, independently of CFI.
> > To be more precise: we normally add type metadata in LTO mode when the class has hidden visibility. See: http://clang.llvm.org/docs/LTOVisibility.html
> > 
> > That doesn't necessarily imply devirtualization, which is controlled by the flag `-fwhole-program-vtables`.
> So with hidden visibility but without CFI or -fwhole-program-vtables, do we split the module? What's the purpose?
At the moment we would. The purpose is to simplify the overall interface. If I want to compile a subset of my TUs without CFI or devirtualization, I should be able to do that by enabling LTO but not passing the CFI or devirtualization flags. In that case the vtables themselves should still have type metadata so that TUs compiled without CFI/devirtualization can correctly interoperate with TUs compiled with CFI/devirtualization (to handle the cases where a class defined in a TU compiled without CFI/devirt is used by code compiled with LTO/devirt, or where the linker/LTO selects a linkonce_odr vtable from a TU compiled without CFI/devirt).

I'd be open to changing the command line interface so that an additional flag may be used to control the scope of the "LTO unit" and which would just enable type metadata, but ideally I'd like to keep things relatively simple.


https://reviews.llvm.org/D28843