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

[Sean Silva 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:
>

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
> 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...
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160524/b3500c38/attachment.html>