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

[Hal Finkel via llvm-commits]

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?

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.


http://reviews.llvm.org/D19950