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

[Xinliang David Li via llvm-commits]

On Mon, May 9, 2016 at 4:49 PM, Hal Finkel <hfinkel at anl.gov> wrote:

> hfinkel added a comment.
>
> 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?
>


You mean when computing BFI (actually BPI which is the input to BFI), let
the client to specify whether to estimate back edge probability
differently) ?  This is doable.  I think when we have enough passes using
BFI, we can visit this topic.



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

Doing it in CGP seems reasonable.

David

>
>
> http://reviews.llvm.org/D19950
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20160509/c88ef0e6/attachment.html>