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

Daniel Berlin via llvm-dev llvm-dev at lists.llvm.org
Wed Aug 24 15:07:40 PDT 2016


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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160824/3d191a77/attachment.html>


More information about the llvm-dev mailing list