llvm dev - Mar 2016 - Use of branch weight metadata in enhanced inliner

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160304/1915db3e/attachment.html>

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160304/abf01f3e/attachment.html>

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>