This is the final change necessary to support CFI with ThinLTO.
TODO: avoid breaking Darwin.
How does this break Darwin?
Can we transform other callers of createBitcodeWriterPass with EmitSummaryIndex = true or EmitModuleHash = true to instead call createWriteThinLTOBitcodePass as you did here, and then remove those parameters from createBitcodeWriterPass?
Is it the case that now we will always split the module with this change? Should that only be done under CFI options?
The only other caller like that is in opt. I think that if we change the "under the hood" parts of opt we should change it to not use a pass at all (c.f. our earlier discussion on D27324), then remove those parameters.
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.
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.
Right, if it was the only reason, I wouldn't be in favor, but you raise a real use case below.
Right, seems legit.
That's what I wasn't sure about :)
Make sense, LGTM as is with this explanation!