[PATCH] Get TargetOptions after parseCodeGenDebugOptions in LTO

[Rafael Espíndola]

So, from the gold api perspective you can you the extra options as
soon as the loop in onload is done.

Maybe the correct change is for LTOModule to not require a target and
have on be passed down as needed? This would be a somewhat big change.
Since the C api is stable, this would be easier to do once tools/gold
is using lib/LTO directly (which I hope to do really soon now).

Also, do you have a testcase where this makes a difference?

Cheers,
Rafael



On 17 June 2014 14:39, Tom Roeder <tmroeder at google.com> wrote:
> This patch adds calls to InitTargetOptionsFromCodeGenFlags after the
> call to parseCodeGenDebugOptions. It then passes a
> correctly-filled-out TargetOptions to LTOCodeGenerator. There are
> currently calls to get the TargetOptions before LTOModule creation,
> but this only gets the default versions of the options, since gold
> doesn't pass the extra options down to lto early enough: the calls
> lto_codegen_debug_options don't happen until all_symbols_read_hook in
> gold, which happens after all the modules have been read, IIUC.
>
> AFAICT, this currently doesn't lead to any problems with
> TargetOptions, but it's a little odd, since LTOModule needs
> TargetOptions in its constructor, but the arguments that specify
> non-default versions of TargetOptions haven't been passed to LTO yet.
>
> Maybe the right fix is to move the call to lto_codegen_debug_options
> earlier in gold? Can someone who knows the sequence of calls in gold
> fill me in?
>
> Thanks,
>
> Tom
>
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
>