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

[Xinliang David Li via llvm-dev]

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:
>
> > 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?
>


I proposed the same change in proposal B in the review thread.

B. Proposed new behavior:
 -fprofile-instr-generate turns on IR late instrumentation
 -fcoverage-mapping turns on FE instrumentation and coverage-mapping
 -fprofile-instr-generate -fcoverage-mapping result in compiler warning
 -fprofile-instr-use=<> will automatically determine how to use the

The upside is that -fcoverage-mapping itself does not do anything by itself
today. This change will simplify its usage (without user specifying
-fprofile-instr-generate)

The downside Sean mentioned is that this changes the existing behavior of
-fcoverage-mapping which can be a surprise to users (though I wonder why
would a user depend on this old behavior).


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

Perhaps clang vs LLVM (similar to the cc1 option we have).  The downside is
'Clang' is clearly tied to Clang, but not any other FEs.


David

>
> > 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...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160524/8bb9bb80/attachment.html>