[PATCH] D33151: ThinLTO: Verify bitcode before lauching the ThinLTOCodeGenerator.

Adrian Prantl via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Tue May 16 16:16:06 PDT 2017


aprantl added a comment.

In https://reviews.llvm.org/D33151#756801, @mehdi_amini wrote:

> In https://reviews.llvm.org/D33151#756793, @aprantl wrote:
>
> > In https://reviews.llvm.org/D33151#756788, @mehdi_amini wrote:
> >
> > > It seems to me that it indicates that the check in the `codegen()` method is redundant now. Why do we need it? What about just removing it?
> >
> >
> > Because llvm-lto invokes codegen() directly after loading the module itself (wihtout going through ThinLTOCodeGenerator for the loading):
>
>
> It is likely before `run()` was improved to be able to handle `CodeGenOnly`, we should retarget llvm-lto to use `run()` instead. I can do this if you want (likely tonight or tomorrow night)






================
Comment at: lib/LTO/ThinLTOCodeGenerator.cpp:186
+    StripDebugInfo(*ModuleOrErr.get());
+  }
   return std::move(ModuleOrErr.get());
----------------
mehdi_amini wrote:
> aprantl wrote:
> > mehdi_amini wrote:
> > > How does it work with lazy-loaded modules?
> > > 
> > How can I simulate a lazy-loaded module using llvm-lto? I would like to add a test for this.
> Anything that do cross-module importing will do lazy-loading. So two modules and one function calling another function in the other module. I think `test/ThinLTO/X86/funcimport.ll ` should have such an example.
> 
If that is so then my cross-module import tests (the last two llvm-lto invocations) are already testing this. The lazy-loaded modules will use the PostProcess verifier in FunctionImport.


https://reviews.llvm.org/D33151





More information about the llvm-commits mailing list