[llvm-dev] libLTO Codegen options issue

[Steven Wu via llvm-dev]

A quick feedback will be that (1) is not an option. libLTO APIs need to be stable and existing APIs cannot be changed.

I am curious about your motivation for the change. If you have access to `InitTargetOptionsFromCodeGenFlags`, then you don't need libLTO interface at all since you are building again LLVM and you are free to call any underlying API you want. 

In libLTO, `parseCodeGenDebugOptions` is a debug function as name suggested. People should not rely on that in production. Instead, new APIs should be created for the underlying setting you need. I don't see reasons why you need to parse CodeGen flags before creating code generator.

Steven

> On Dec 3, 2020, at 2:57 PM, Wael Yehia <wyehia at ca.ibm.com> wrote:
> 
> Hi,
> We're trying to use libLTO, and noticed an issue (more of a timing problem) with option processing where TargetOptions is created before cl::ParseCommandLineOptions is invoked.
> Right now, the only place where 
>  ParseCommandLineOptions is called is in LTOCodeGenerator::parseCodeGenDebugOptions, 
>  which is only called from maybeParseOptions,
>  which is called after TargetOptions have been created.
> We construct TargetOptions (by calling InitTargetOptionsFromCodeGenFlags) first and then use it to we create modules or the codegen object.
> 
> Assuming this is in fact a problem, one way to fix this is to decouple parseCodeGenDebugOptions from LTOCodeGenerator, so that it can be called before we create the LTOCodeGenerator.
> 
> Now we can either 
>   (1) modify the signature of the lto_codegen_debug_options and lto_codegen_debug_options_array API functions 
> or (2) add new API functions.
> 
> I prefer (1) because as it is now, the API is broken.
> I uploaded a patch here https://reviews.llvm.org/D92611
> 
> Any feedback is appreciated. Thank you
> 
> Wael
>