[PATCHES] A module inliner pass with a greedy call site queue

Chandler Carruth chandlerc at google.com
Wed Aug 27 12:33:26 PDT 2014


On Wed, Aug 27, 2014 at 11:52 AM, Yin Ma <yinma at codeaurora.org> wrote:

> For iterative framework for inliner and other optimization, for inliner
> itself, I believe two
>
> passes should be good enough, one at the very beginning of a pass queue
> and one at the
>
> end.  In general, the size of IR is very linear to the one after
> optimization.
>

This is definitely not the case.

Things like SROA, SSA-formation, and DCE after constants are propagated
thanks to SROA, GVN etc., will often dramatically change the code size.
Perhaps it is the case for very small isolated benchmarks that have already
been heavily optimized by hand, but across almost all the code and
benchmarks I care about in the real world (sadly, SPEC is not the real
world or even close) the size of IR after optimization has much higher
variance -- sometimes it is *much* smaller.


> Some optimizations
>
> increases the ir size, such as unrolling. For increased Ir callees,
> actually, for most of time, we
>
> do not inline it again in the iterative framework. So if we only add
> another pass to catch
>
> all decreased ir callees, it should be enough in my opinion.
>

You're not addressing the case when inlining itself *changes* how much the
optimizer decreases the IR... When that happens, you really need to iterate
with the inliner to get the best results.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20140827/d4f205c2/attachment.html>


More information about the llvm-commits mailing list