[PATCH] D31100: [LTO] Allow client to skip code gen

[Mehdi AMINI via Phabricator via llvm-commits]

mehdi_amini added a comment.

In https://reviews.llvm.org/D31100#704477, @tejohnson wrote:

> > So I rather get clang to initialize the TargetOptions in the LTO config. I think it should be easy to extract `EmitAssemblyHelper::CreateTargetOptions` out of `EmitAssemblyHelper::CreateTargetMachine` and reuse it for this purpose.
>
> That is doable, but I don't see the advantage of duplicating the logic in EmitAssemblyHelper (e.g. CreateTargetMachine), just so we can invoke the codegen through LTO, since we have to be able to do this outside LTO in EmitAssemblyHelper in the non-LTO case in clang. We have to set up TargetOptions in either case, see below.


Not clear which duplicating logic you're referring to right now? I'm talking about *reusing* the logic (OK I may miss something because I haven't looked deep enough).

>> Not sure what you mean here, I suspect this is why I'm against using a different flow: we're not supposed to be passing flags differently one case from the other.
> 
> There's not much choice here I think. In the case of doing a ThinLTO backend via clang, this information is passed in memory in the CodeGenOptions data structure. That is used to fill in the TargetOptions data structure in EmitAssemblyHelper::CreateTargetMachine.
> 
> In the in-process gold case, it needs to be passed from clang into the gold plugin somehow, which can't be done directly via the CodeGenOptions data structure, so we pass internal options. Then the gold plugin is responsible for getting those to init the TargetOptions (as you note above it does that via InitTargetOptionsFromCodeGenFlags).
> 
> So regardless of whether the clang invocation of the ThinLTO backends uses LTO to do the code gen, and sets up the TargetOptions struct within lto::Config, or just uses the existing EmitAssemblyHelper which sets up the TargetOptions there, the setup of TargetOptions is up to the LTO client.

What I'm loooking at is to have the guarantee that by dumping (serializing) the lto::Config, you get all the information to reproduce. Ultimately I'd like to include this as part of "save-temps" and be able to reload the config to replay a backend. Having a single API all the way helps to setup something like this.


https://reviews.llvm.org/D31100