[PATCH] D18069: Throttling LICM to reduce compile time of Value Propagation and Reg Splitting

[Daniel Berlin via llvm-commits]

On Fri, Mar 11, 2016 at 5:48 PM, Wei Mi <wmi at google.com> wrote:

> Note: Stretched vars are not only affecting performance of Value
> Propagation, but also register allocation (Reg Splitting). As Daniel
> said, for the compile time problem in Value Propagation, it could be
> solved in an eager way.  But it still hurts the compile time of reg
> alloca for which I don't have an easy solution.
>

There are not always easy solutions. But at some point, we have to do what
we need to do :)


>
> Actually I am not convinced that doing LICM as many as possible is
> indispensible to canonicalize IR. As far as I know, Gcc throttle LICM
> too, in middle end.


GCC has two things that do LICM, PRE and tree-loop-licm.

PRE does whatever it wants. It is not throttled by register pressure.

tree-ssa-im.c (LICM) is more restrained, and has a cost calculation for how
expensive something is to move.

(the next question is usually: what cases do the two cover.  In GCC, PRE
will get loads and scalars. LICM will do those and stores.  LICM tries as
bunch harder to identify the specific case of  loop invariant expressions
that are equivalent.
At one point, because there was no alias oracle in GCC, LICM got more
loads. I"m not sure this is true anymore, and not sure anyone has checked
to see if it does anything with loads/scalars anymore)



> And I don't think doing opt aggressively without known benefit and
> then nullify it is a good idea.


This is a common point of contention in compilers.
IME, most compilers fall on the side of "we don't try to take register
pressure into account in the middle, because it's really hard to say what
is going to happen 10+ passes down the road, and not easy to estimate
accurately on today's architectures".

GCC and LLVM definitely fall into that case.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20160312/78234cae/attachment.html>