Add -fauto-profile option to Clang driver

[Diego Novillo]

On Tue, Oct 22, 2013 at 5:53 PM, Kaelyn Uhrain <rikka at google.com> wrote:
> On Tue, Oct 22, 2013 at 2:28 PM, Diego Novillo <dnovillo at google.com> wrote:
>>
>> On Tue, Oct 22, 2013 at 5:06 PM, Chandler Carruth <chandlerc at google.com>
>> wrote:
>> >
>> > On Tue, Oct 22, 2013 at 1:58 PM, Bob Wilson <bob.wilson at apple.com>
>> > wrote:
>> >>
>> >> I really like GCC's -fprofile-generate and -fprofile-use, except I
>> >> don't
>> >> think we should reuse those names for something that works differently.
>> >> My
>> >> overall preference would be something like this (using those names as
>> >> placeholders):
>> >>
>> >> -fprofile-generate=<instrumentation-style>
>> >> -fprofile-use=<profile-style>
>> >>
>> >> e.g., "-fprofile-use=auto".  That would at least unify the new options.
>> >> In fact, we may even be able to reuse those option names with
>> >> -fprofile-use
>> >> being a synonym for -fprofile-use=gcc, which matches gcc's option.  I'm
>> >> not
>> >> at all familiar with how that option actually works in gcc, so I can't
>> >> say
>> >> whether that would make sense.
>> >
>> >
>> > I don't think we can re-use '-fprofile-use' in a way different from GCC
>> > here. GCC accepts it as "-fprofile-use=/path/..." and i could call my
>> > profile file "auto" or "gcc" or "clang" and expect it to work.
>> >
>> > I think it is best for instrumentation-based profiling to use
>> > '-fprofile-generate' and '-fprofile-use' just like GCC does, if with
>> > different file formats, etc.
>>
>> Agreed.
>>
>> > I don't see in flags in upstream GCC regarding sample-driven profiling,
>> > but
>> > "auto" I think is actively harmful in the name. There is nothing
>> > intrinsically automatic about it. It is "external" in the sense that it
>> > isn't from compiled-in instrumentation, but I don't see any reason for
>> > "auto" to indicate that to the user.
>>
>> GCC (well the Google branch now) uses -fauto-profile for the
>> sample-driven profiling. The external profiler actually generates a
>> gcov file.  The two options -fprofile-generate and -fprofile-use are
>> strictly for instrumentation based profiling.  Our internal users are
>> already using -fauto-profile in their builds.
>>
>> Dehao (CCd) tells me that the option was initially named
>> -fsample-profile, but they then renamed it to -fauto-profile.
>>
>> > I think for now, we should put this functionality behind a specific flag
>> > whose name is indicative of the user's expected behavior. The best idea
>> > I've
>> > seen is "-fsample-profile=/path/..." but I'd love to hear better
>> > suggestions.
>>
>> I don't really have better names.  -fsample-profile and -fauto-profile
>> are both the same to me.  The name -fauto-profile has the slight
>> advantage that it can serve as a more general flag name, with the
>> actual profiling style automatically detected by the format of the
>> input file. But, I don't really care all that much.
>>
>> Having said that, I can also see -fprofile-use=filename being smart
>> enough to know what type of profile it's getting by examining the
>> signature of "filename".  This is contemplated in my LLVM patch.  The
>> pass instantiates a different reader according to the type of file it
>> detects (right now it does nothing of the sort, however).
>
>
> My $0.02 having just read the recent discussion: particularly if/when
> -fprofile-use=filename is smart enough to detect the type of profile,
> instead of having -f*-profile options like -fsample-profile, perhaps
> -fprofile-type=<kind> (e.g. -fprofile-type=sample, -fprofile-type=gcc,
> etc--or -fprofile-kind=<kind> instead of -fprofile-type) where the type
> defaults to GCC style... or later to whatever -fprofile-use= guesses the
> file's format to be. It also gives pretty good symmetry to
> -fprofile-generate= and -fprofile-use=

I quite like this approach.  I'm hoping we won't need -fprofile-type,
but it's a good escape hatch to override auto detection.

This is the revised patch.  I'm not changing the name of the flag just
yet until we reach consensus.


Thanks.  Diego.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Add-fauto-profile-to-Clang-s-driver.patch
Type: application/octet-stream
Size: 5732 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20131022/fd210ca5/attachment.obj>