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

[Xinliang David Li via llvm-commits]

On Sat, Mar 12, 2016 at 11:05 AM, Wei Mi <wmi at google.com> wrote:

> > GCC has two things that do LICM, PRE and tree-loop-licm.
>
> Thanks for the explanation of PRE and LICM in GCC.
>
> >> 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.
> >
>
> Agree that usually we don't try to take register pressure into account
> in the middle. But there is special case, like llvm interleave in
> vectorization. I also don't try to get a precise register model to use
> in middle end. I just want to obviate apparent non-beneficial cases
> which only increase compile time. That is why I do the throttling in a
> constrain way -- only on very large loops, only on cheap instruction,
> and only when reg pressure is high based on estimation.
>

The question is whether the compile time increase is due to LICM or caused
by inefficiency in other part of the LLVM that gets exposed by LICM. If
LICM is not the root cause, fixing it here does look like the wrong place
(aka, papering over the real problem else where).

Regarding register pressure aware LICM,  fixing register rematerialization
logic and making it more powerful can go a long way.

thanks,

David


>
> If I still see perf regression, I may either try getting the constrain
> more strictly, or reflect if there is real deficiency to do it in this
> way. It will be based on more testing (For my limited testing -- llvm
> testsuite and google internal perf testing on x86-64, I havn't seen
> regressions for now).
>
> Thanks,
> Wei.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20160312/6d4b6b40/attachment.html>