[cfe-dev] RFC - Stop ignoring -fprofile-generate and -fprofile-use

Diego Novillo dnovillo at google.com
Wed Jun 17 15:07:20 PDT 2015


On Wed, Jun 17, 2015 at 5:34 PM, Justin Bogner <mail at justinbogner.com>
wrote:

> On 2015 Jun 17, at 13:53, Diego Novillo <dnovillo at google.com> wrote:
>
> >   • -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?
>

Sure. Sounds reasonable.


> 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.


Sure.  But this may have a wrinkle. The problem here is that GCC already
has a different option for sample profiles (-fauto-profile). Someone using
the same flags for both compilers (or migrating off of GCC) might find this
problematic. Although, I can't really think a scenario where this would
happen.

In a sense, anything that is a superset of GCC's current behaviour should
be fine. So, I suppose this is OK.



> I'd limit
> this to the path-to-a-file case though, I think it's too magical when
> pointing at a directory.
>

Agreed.


Diego.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20150617/560f3435/attachment.html>


More information about the cfe-dev mailing list