Bah, forgot to actually CC Deaho. Fixed.
On Tue, Oct 22, 2013 at 5: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). > > > Diego. _______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
