On Oct 22, 2013, at 10:38 AM, Diego Novillo <[email protected]> wrote:
> On Tue, Oct 22, 2013 at 1:26 PM, Chandler Carruth <[email protected]> > wrote: >> >> On Tue, Oct 22, 2013 at 10:23 AM, Diego Novillo <[email protected]> wrote: >>> >>> On Tue, Oct 22, 2013 at 1:18 PM, Chandler Carruth <[email protected]> >>> wrote: >>> >>>> I wonder if the better way to go is to start with a very narrow flag >>>> name, >>>> and generalize it when the infrastructure for more generalized profile >>>> reading arrives? Supporting a highly specific flag for a long time >>>> doesn't >>>> seem like a high cost. >>> >>> You mean add -f<blah>-profile as we add more capabilities and make >>> this one be -fsample-profile? >> >> >> And, if we end up with a single common profile format at some point, we can >> merge. But let's see what others think as well. > > Sure. Bob, have you any thoughts on this? ISTR you were also > wondering what to name the profiling flags you are working on. The approach that I've been developing will not have a common profile format with auto-profile, or at least that wouldn't make any sense, since the profile data is read directly by the front-end. From the user's point of view, though, that is an implementation detail, isn't it? I'm not good with names, but I do think it's important. Once people start using the options, it will be extremely hard to change them, so I don't think we should try to defer this decision. Ideally we could make some progress toward more consistent options, or at least not make things too much worse. Here's what we've got now: -fcreate-profile: This appears to be something that Apple added to gcc for some previous incarnation of PGO; clang treats it as a synonym for -fprofile-arcs -fprofile-arcs: gcc-compatible option for gcov-style profiling. -fprofile-generate: gcc option for PGO; recognized by the clang but treated as a synonym for -fprofile-arcs --profile-blocks / -a: some ancient prof thing; probably not implemented --profile / -p: more ancient prof stuff; probably not implemented -pg: mount instrumentation for gprof --coverage / -ftest-coverage: for gcov -finstrument-functions: something completely different In addition, we have the following options that were added recently. They are ignored but clang recognizes them to avoid errors about unrecognized options: -fprofile-dir=<dir> -fprofile-use -profile -profile-correction -profile-generate-sampling -profile-reusedist -profile-values So if you're a new clang user it may be somewhat daunting to figure out what option you're supposed to use! 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. _______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
