[LLVMdev] RFC - Stop ignoring -fprofile-generate and -fprofile-use
Justin Bogner
mail at justinbogner.com
Wed Jun 17 15:37:01 PDT 2015
Diego Novillo <dnovillo at google.com> writes:
> 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.
Convince gcc to do this too? ;)
I'm not terribly attached to this idea if you think it's a bad precedent
to set or something, but it does seem like it'd be convenient enough to
be worthwhile.
> In a sense, anything that is a superset of GCC's current behaviour should be
> fine. So, I suppose this is OK.
More information about the llvm-dev
mailing list