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

[Xinliang David Li]

On Wed, Jun 17, 2015 at 3:07 PM, Diego Novillo <dnovillo at google.com> wrote:
>
>
> 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.
>

yes -- you are not removing the old behavior.

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