On Tue, Oct 22, 2013 at 5:53 PM, Kaelyn Uhrain <[email protected]> wrote: > On Tue, Oct 22, 2013 at 2:28 PM, Diego Novillo <[email protected]> wrote: >> >> On Tue, Oct 22, 2013 at 5:06 PM, Chandler Carruth <[email protected]> >> wrote: >> > >> > On Tue, Oct 22, 2013 at 1:58 PM, Bob Wilson <[email protected]> >> > 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.
0001-Add-fauto-profile-to-Clang-s-driver.patch
Description: Binary data
_______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
