[llvm-dev] GSoC Proposal : Path Profiling Support

[Snehasish Kumar via llvm-dev]

Hi Vedant,

Thanks for the feedback. I've updated the draft.

> It would be nice to get feedback from potential users of path profile
information, like people who work on GVN.
>
> - It would be nice to measure the performance variation between programs
>   optimized with edge-based profiles vs. with path profiles.

To my knowledge currently there are few consumers of edge profiles.
Replacing them with path profiles will not yield any different results
as it is used now.
Implementing deeper optimizations correlated to the paths executed will show
better results than edge profiles (eg. Superblock formation).

> - I'd be curious to see comparisons with the instrprof framework (compile time,
>   exec time, profile size, binary size). This would establish a concrete target
>   to beat.

This is definitely something we can analyse further though in my
opinion it may not
be a fair target to "beat" as path profiles subsume edge profiles.

>
>
>> David, Vedant it would be great if I could get some advice on refining
>> the goals and particulars of the implementation.
>> The version we use internally is not performance oriented and will
>> require refactoring.
>> Here is a link to the draft document [1].
>>
>> [1] https://docs.google.com/document/d/18i9FvD7FSqX6tNEXb83gzc0EC_STeS3bWOVf167sFWk/edit?usp=sharing
>>
>>>>>>> Open Issues :
>>>>>>> + Update PathProfileInfo on CFG transformations ?
>>>>>
>>>>>> Could you clarify what this means?
>>>>>
>>>>> Changing the control flow graph of a routine may invalidate collected path
>>>>> profiles. For example, splitting a block with an unconditional branch does
>>>>> not change the profile, but introducing a conditional branch invalidates the
>>>>> profile. The issue I would like to address is which transformations should
>>>>> we allow as safe transformations and how should we update the internal path
>>>>> profile data structures if we allow this at all.
>
> It seems that existing optimization passes can make changes that could invalidate
> a path profile. Is it expensive to detect these changes and invalidate the affected
> portions of the profile?

*Speculation* Detecting portions to invalidate should be easy but depends on the
nature of the change.

>
> vedant
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev