[LLVMdev] RFC - Stop ignoring -fprofile-generate and -fprofile-use

[Diego Novillo]

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.

>From https://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html:

-fprofile-generate-fprofile-generate=pathEnable 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=pathEnable 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:

   1. -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.
   2. -fprofile-use=path-prefix would cause the compiler to read from
   <path-prefix>/default.profile.
   3. I could also add support for -fprofile-dir, but we don't really use
   it internally.

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150617/4e979033/attachment.html>