[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