[llvm-dev] The state of IRPGO (3 remaining work items)
Sean Silva via llvm-dev
llvm-dev at lists.llvm.org
Tue May 24 17:23:10 PDT 2016
On Tue, May 24, 2016 at 3:50 PM, Duncan P. N. Exon Smith <
dexonsmith at apple.com> wrote:
> Zooming into the command-line option bike-shed:
Let's avoid bikeshedding until the exact requirements are clear.
-- Sean Silva
> > 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
> I feel like this would be simpler:
> * -fcoverage-mapping: -fprofile-instr-generate=FE + coverage
> 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...
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the llvm-dev