[llvm-dev] The state of IRPGO (3 remaining work items)

Duncan P. N. Exon Smith via llvm-dev llvm-dev at lists.llvm.org
Tue May 24 15:50:27 PDT 2016


Zooming into the command-line option bike-shed:

> On 2016-May-24, at 15:41, Vedant Kumar via llvm-dev <llvm-dev at lists.llvm.org> wrote:
> 
> At its core I don't think -fprofile-instr-generate *implies* FE-based instrumentation. So, I'd like to see the driver do this (on all platforms):
> 
>  * -fprofile-instr-generate: IR instrumentation
>  * -fprofile-instr-generate=IR: IR instrumentation
>  * -fprofile-instr-generate=FE: FE instrumentation
>  * -fprofile-instr-generate -fcoverage-mapping: FE + coverage instrumentation

I feel like this would be simpler:
  * -fcoverage-mapping: -fprofile-instr-generate=FE + coverage instrumentation

Maybe there's a downside I'm not seeing though?

Also, I don't like "FE".  Maybe "source"?  And instead of "IR", "llvm-ir" or something?

> It's a bit ugly because the meaning of -fprofile-instr-generate becomes context-sensitive. But, (1) it doesn't break existing common workflows and (2) it makes it easier to ship IRPGO. The big caveat here is that we'll need to wait a bit and see if our internal users are OK with this.
> 
> One alternative is to introduce a separate driver flag for IRPGO. This might not work well for Sony's existing users. I'd be interested in any feedback about this approach.

My first thought is `-mprofile-instr-generate`, since if it's not in the frontend then "-f" doesn't really make sense...


More information about the llvm-dev mailing list