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

Wei Mi via llvm-dev llvm-dev at lists.llvm.org
Fri Aug 19 15:57:55 PDT 2016


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. Correct me if I say something wrong here. I am also
wondering if llvm doesn't have such complex transformations on SCEV
(including so many simplifications and canonicalizations), what will
be missing? Why IR based canonicalization and simplification not
enough?

Thanks,
Wei Mi.


More information about the llvm-dev mailing list