[llvm-dev] Use of branch weight metadata in enhanced inliner

Xinliang David Li via llvm-dev llvm-dev at lists.llvm.org
Fri Mar 4 11:21:36 PST 2016


Right.

For non PGO use cases, we also need to measure more carefully compile time
and memory overhead (especially in LTO, thinLTO contexts) of this change
and decide what is right strategy (e.g, by default at O2 or higher opt
level).

David

On Fri, Mar 4, 2016 at 11:15 AM, Easwaran Raman via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

> Hi Taewook,
>
> There is no reason not do use BFI in non-PGO mode. My current priority is
> to improve PGO performance and I wanted to isolate this as much as possible
> - hence it is turned on only in PGO mode.
>
> - Easwaran
>
> On Fri, Mar 4, 2016 at 10:54 AM, Taewook Oh <twoh at fb.com> wrote:
>
>> Thank you Easwaran for landing a great diff that enables the use of block
>> frequency information in inliner. As of now, it seems that inliner can
>> exploit the information only when profile data is available. However,
>> instructions such as __builtin_expect may set branch weight metadata as
>> well, which is useful for inliner.
>>
>> I think this problem can be addressed by letting llvm::getInlineCost
>> function to use BlockFrequencyAnalysis regardless of availability of
>> profile data, and making CallAnalyzer::updateThreshold to use callsite
>> frequency instead of callsite count. Is there a reason that we allow
>> inliner to use block frequency information only when profile data is given?
>>
>> Thanks,
>> Taewook
>>
>
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160304/02384f75/attachment.html>


More information about the llvm-dev mailing list