[LLVMdev] RFC - Stop ignoring -fprofile-generate and -fprofile-use
Justin Bogner
mail at justinbogner.com
Wed Jun 17 14:34:17 PDT 2015
On 2015 Jun 17, at 13:53, Diego Novillo <dnovillo at google.com> wrote:
> The flags -fprofile-generate and -fprofile-use are currently ignored
> for GCC compatibility. I would like to enable them and give them
> similar semantics to GCC. These flags are baked pretty deeply into
> our build environment, so supporting them at the driver level will
> make our lives a lot simpler.
This seems like a fairly reasonable idea. We'll have to make sure it's
clear (in the docs or whatever) that you can't use clang to generate a
profile and gcc to consume it and vice versa, but that doesn't seem like
a big deal.
> From https://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html:
>
> -fprofile-generate
> -fprofile-generate=path
> Enable options usually used for instrumenting application to produce
> profile useful for later recompilation with profile feedback based
> optimization. You must use -fprofile-generate both when compiling
> and when linking your program.
> The following options are enabled: -fprofile-arcs, -fprofile-values, -fvpt.
>
> If path is specified, GCC looks at the path to find the profile
> feedback data files. See -fprofile-dir.
>
> -fprofile-use
> -fprofile-use=path
> Enable profile feedback-directed optimizations, and the following
> optimizations which are generally profitable only with profile
> feedback available: -fbranch-probabilities, -fvpt, -funroll-loops,
> -fpeel-loops, -ftracer, -ftree-vectorize, and
> ftree-loop-distribute-patterns.
> By default, GCC emits an error message if the feedback profiles do
> not match the source code. This error can be turned into a warning
> by using -Wcoverage-mismatch. Note this may result in poorly
> optimized code.
>
> If path is specified, GCC looks at the path to find the profile
> feedback data files. See -fprofile-dir.
>
>
> Note that the argument to -fprofile-generate and -fprofile-use is
> not a file name. It is a path prefix used to store the generated
> profile (in GCC's case, each object file in the binary generates its
> own profile file). In Clang, the flags would do the following:
>
> • -fprofile-generate=path-prefix would cause the instrumented
> binary to write the profile <path-prefix>/default.profraw. If
> <path-prefix> does not exist, it is created by the runtime.
> • -fprofile-use=path-prefix would cause the compiler to read
> from <path-prefix>/default.profile.
The path-prefix versions are a bit of an odd fit for the instrprof
stuff - I'd prefer if they dealt with the path to the file. I can see
how that might be difficult to do and still be compatible though.
Maybe we could make the -fprofile-use= version accept a file or
directory, and if a directory is specified then look for the default?
The other thing that would be nice would be if -fprofile-use=path could
autodetect which kind of profile the path is - that is, It'd be nice to
accept both instrprof and sample profiles with this option. I'd limit
this to the path-to-a-file case though, I think it's too magical when
pointing at a directory.
> • I could also add support for -fprofile-dir, but we don't
> really use it internally.
I don't think it's necessary unless someone actually wants to use it.
> As with -fprofile-instr-generate, LLVM_PROFILE_FILE would override
> the path prefix and name of the profile file.
>
> Does this sound reasonable?
>
>
> Thanks. Diego.
More information about the llvm-dev
mailing list