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

[Hal Finkel via llvm-commits]

----- Original Message -----
> From: "Wei Mi" <wmi at google.com>
> To: "Daniel Berlin" <dberlin at dberlin.org>
> Cc: "Philip Reames" <listmail at philipreames.com>, reviews+D18069+public+889dfe1c8e777520 at reviews.llvm.org, "Andrew
> Trick" <atrick at apple.com>, "Hal Finkel" <hfinkel at anl.gov>, "Geoff Berry" <gberry at codeaurora.org>, "David Li"
> <davidxl at google.com>, "llvm-commits" <llvm-commits at lists.llvm.org>
> Sent: Saturday, March 12, 2016 1:05:52 PM
> Subject: Re: [PATCH] D18069: Throttling LICM to reduce compile time of Value Propagation and Reg Splitting
> 
> > 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 problem is not that your restrictions are unreasonable, but that people also *write* code with this problem, and for the same reason you're motivated to restrict LICM, we do a poor job compiling that code too. Improving the backend to handle this situation better fixes both problems, whereas restricting LICM improves only a subset (modulo modeling difficulties and other optimization losses).

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

-- 
Hal Finkel
Assistant Computational Scientist
Leadership Computing Facility
Argonne National Laboratory