[llvm-dev] Request suggestions about how to remove redundencies caused by SCEV expansion fundementally

Hal Finkel via llvm-dev llvm-dev at lists.llvm.org
Sat Aug 27 19:07:30 PDT 2016


----- Original Message -----
> From: "Wei Mi via llvm-dev" <llvm-dev at lists.llvm.org>
> To: "Daniel Berlin" <dberlin at dberlin.org>
> Cc: "llvm-dev" <llvm-dev at lists.llvm.org>, "David Li" <davidxl at google.com>
> Sent: Wednesday, August 24, 2016 5:41:12 PM
> Subject: Re: [llvm-dev] Request suggestions about how to remove redundencies caused by SCEV expansion fundementally
> 
> On Wed, Aug 24, 2016 at 3:07 PM, Daniel Berlin <dberlin at dberlin.org>
> wrote:
> >
> >
> > On Fri, Aug 19, 2016 at 3:57 PM, Wei Mi via llvm-dev
> > <llvm-dev at lists.llvm.org> wrote:
> >>
> >> SCEV expansion sometimes generates redundent expr even if there is
> >> an
> >> available expr which can be reused. The redundent exprs can be a
> >> lot
> >> different from existing exprs so that existing cleanup passes
> >> cannot
> >> remove them.
> >>
> >> https://llvm.org/bugs/show_bug.cgi?id=24920
> >> https://llvm.org/bugs/show_bug.cgi?id=24442
> >>
> >> https://reviews.llvm.org/D12090 and
> >> https://reviews.llvm.org/D21313
> >> already relieved the problem somewhat, but it is far from being
> >> solved
> >> fundamentally. Recently we found another problematic case
> >> described in
> >> https://llvm.org/bugs/show_bug.cgi?id=29065. And I believe I can
> >> create more tests revealing similar problems.  In PR29065, I
> >> explained
> >> why it is difficult to fix the problem by extending D12090 and
> >> D21313.
> >> It is possible but still not very easy to fix the problem by
> >> enhancing
> >> existing cleanup passes. So I am soliciting ideas here about how
> >> to
> >> solve the problem in a more fundamental way.
> >>
> >> One thing I am always wondering is GCC also uses SCEV to calculate
> >> the
> >> loop iteration number and why it doesn't have such problem. From
> >> my
> >> limited knowledge about GCC's SCEV I guess it is because gcc only
> >> has
> >> the basic function of SCEV which can represent loop recursive expr
> >> like llvm SCEVAddRecExpr part, SCEV operands are still gimple
> >> variables and it doesn't have such complex transformations on SCEV
> >> as
> >> llvm does.
> >
> >
> > This is not really correct :)
> >
> > In fact, at one point, GCC had *all of the possible scev*
> > (sebastian worked
> > a lot on it) ,including mixers, etc.
> >
> >
> > The real thing here is that  GCC just doesn't do a lot of scev
> > expansion. It
> > mainly uses it as an analysis, not as a code generation mechanism.
> >
> >
> 
> You are right, Thanks! I just looked at loop iteration number
> computation in GCC. It only uses SCEV to identify simple induction
> variables, represent them as affine expr, and then use those affine
> exprs and their value ranges in loop to compute loop iteration
> number,
> so it doesn't involve SCEV expansion.

So how are you thinking about moving forward here?

 -Hal

> 
> Wei.
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
> 

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


More information about the llvm-dev mailing list