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.
