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

[Sean Silva via llvm-dev]

On Tue, May 24, 2016 at 4:10 PM, Xinliang David Li <davidxl at google.com>
wrote:

>
>
> 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).
>

I didn't really intend to say that it was a "downside" per se. I was just
pointing it out that it is a separable step and orthogonal to the
discussion. I agree that it would simplify things for users; we already
prohibit -fcoverage-mapping by itself, so we are strictly expanding what we
accept.

-- Sean Silva


>
>
>>
>> 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/929a4222/attachment.html>