[PATCH] D19950: Use frequency info to guide Loop Invariant Code Motion.

[Dehao Chen via llvm-commits]

On Tue, May 10, 2016 at 11:48 AM, Xinliang David Li <davidxl at google.com>
wrote:

>
>
> On Tue, May 10, 2016 at 11:01 AM, Dehao Chen <danielcdh at gmail.com> wrote:
>
>> danielcdh added a comment.
>>
>> In http://reviews.llvm.org/D19950#425287, @hfinkel wrote:
>>
>> > In http://reviews.llvm.org/D19950#425286, @hfinkel wrote:
>> >
>> > > In http://reviews.llvm.org/D19950#425285, @davidxl wrote:
>> > >
>> > > > Static prediction has been conservative in estimating loop trip
>> count -- it produces something like 30ish iterations. If the a very hot
>> loop has a big if-then-else (or switch), it is very likely to mark many
>> bbs' to be colder than the loop header.   Turning on this for static
>> prediction really depends on the false rate. It seems to be this can get
>> wrong pretty easily for very hot loops (which is also the most important
>> thing to optimize for).
>> > >
>> > >
>> > > This is a good point. There's no universal conservative choice
>> (assuming a small trip count is conservative in some cases, and assuming a
>> large trip count is conservative in other cases).
>> >
>> >
>> > Would it be better (and practical) if there were some way for the BFI
>> client to specify which kind of 'conservative' is desired?
>> >
>> > Also, why are we doing this instead of sinking later (in CGP or
>> similar)? LICM can expose optimization opportunities, plus represents a
>> code pattern the user might input manually. Sinking later seems more robust.
>>
>>
>> I looked at CGP pass, looks like it's handling the sinking case-by-case
>> (e.g. there is separate routine to handle sinking of load, gep, etc. I'm
>> afraid this would miss opportunities. Additionally, the file-level comment
>> of CGP pass says "This works around limitations in it's
>> basic-block-at-a-time approach. It should eventually be removed."
>>
>
>
> Perhaps you can do profile driven sinking CGP separately to handle
> manually hoisted code situation mentioned by Hal.
>

Do you mean we still use frequency to decide whether to hoist code in LICM,
additionally use frequency info to check if we want to sink instructions in
CGP?

Dehao


>
> David
>
>
>>
>> I'm not quite clear why it helps to move code out of loop early and later
>> sink it inside. Could you give an example or some more context?
>>
>> Thanks,
>> Dehao
>>
>>
>> http://reviews.llvm.org/D19950
>>
>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20160510/61a68f9b/attachment.html>