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

[Xinliang David Li via llvm-commits]

On Tue, May 10, 2016 at 1:03 PM, Dehao Chen <danielcdh at gmail.com> wrote:

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


yes -- that is the suggestion.

David




>
> 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/f45d74a1/attachment.html>