[PATCH] D57422: [LTO] Set CGOptLevel in LTO config.

Tue Jan 29 17:36:17 PST 2019

sbc100 added a comment.

BTW, it looks like -O0 gets added to the bitcode as `optnone`, but O2 <https://reviews.llvm.org/owners/package/2/> and O3 <https://reviews.llvm.org/owners/package/3/> produce identical bitcode.

In D57422#1376492 <https://reviews.llvm.org/D57422#1376492>, @pcc wrote:

> In D57422#1376482 <https://reviews.llvm.org/D57422#1376482>, @sbc100 wrote:
>
> > I see.    So there should be enough information in each of the bitcode files to set the CGOptLevel accordingly for each function?
>
>
> Not yet. It would need to be added and the cg passes taught to respect it.

In that case would you envisage even clang eventually not setting CGOptLevel globally and let each function set it own level?

> 
> 
>> The fact that gold saw a performance regression is suspicious no?  Does that mean there is performance gain we can get by adding it here?
> 
> The user who saw the perf regression was using `--lto-O3` IIRC. One of the proposed interim solutions was to use CGOptLevel = 2 for `--lto-O[0-2]` and CGOptLevel = 3 for `--lto-O3`, but I never got around to writing a patch for it.
> 
>> Perhaps we should remove the CGOptLevel from the LTO completely once we remove it from gold?   It looks like tools/llvm-lto2/llvm-lto2.cpp also does that same thing BTW.
> 
> Yes, that's the eventual plan.

In that case would you mind if I landed this change for now with a TODO to remove this code once the opt level for each function is plumbed through from the frontend?   (Today it looks like only O0 is plumbed through),  It seems that being consistent with the other LTO tools would be good for the time being, and there would be an immediate benefit for users who are passing --lto-O3.

Repository:
  rLLD LLVM Linker

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D57422/new/

https://reviews.llvm.org/D57422