vitalybuka added a comment. In https://reviews.llvm.org/D42995#1000025, @tejohnson wrote:
> > Empty ThinLTOIndexFile signals that we don't need this module during > > linking. > > Not the only case actually. We now also pass an empty index file when we want > to compile the bitcode down to object without applying any LTO optimization > (there are a few cases where we decide we want to turn off LTO optimizations > for some links), and this is currently relying on being able to pass > /dev/null for the index file that would be broken by this change. I'd expect this should be done by indexing and content is already in the merged object file. Not sure how to reproduce this. I've build some large targets and I never seen this. > > >> So we should not run ThinLTO backend even if it contains the >> ThinLTO module. Backend may fail because of lack of necessary >> information which should be provided by ThinLTOIndex. > > This shouldn't happen - are you seeing cases where we fail? After > loadModule() is called, EmitBackendOutput() is called which passes > /*IgnoreEmptyThinLTOIndexFile*/true to getModuleSummaryIndexForFile, which > would cause it to return nullptr if the index file is empty. Back in > EmitBackendOutput(), if the combined index is null we will skip ThinLTO > compilation and fall back to normal compilation. I don't see for regular compilation, but I see for for CFI. Backend will not be able to process llvm.type.test without TypeIdMap from index and it will crash in "Instruction Select" https://reviews.llvm.org/D42995 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
