[llvm-bugs] [Bug 46457] New: ScalarEvolution Add expression type tracking woes

via llvm-bugs llvm-bugs at lists.llvm.org
Thu Jun 25 08:24:24 PDT 2020


            Bug ID: 46457
           Summary: ScalarEvolution Add expression type tracking woes
           Product: libraries
           Version: trunk
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: Global Analyses
          Assignee: unassignedbugs at nondot.org
          Reporter: lebedev.ri at gmail.com
                CC: llvm-bugs at lists.llvm.org

SCEVAddExpr contains the following:

    Type *getType() const {
      // Use the type of the last operand, which is likely to be a pointer
      // type, if there is one. This doesn't usually matter, but it can help
      // reduce casts when the expressions are expanded.
      return getOperand(getNumOperands() - 1)->getType();

That's great, we've saved whole sizeof(pointer) bytes, and it *almost* always
Except it's very much not guaranteed, and can break.

For example, see: https://godbolt.org/z/L8BZyJ
  %arrayidx1 = getelementptr inbounds [1 x i8], [1 x i8]* %arrayidx, i64 0, i64
  -->  ({((sext i32 %base to i64) + %e)<nsw>,+,1}<nsw><%for.cond> +
%sub.ptr.div)<nsw> U: full-set S: full-set      Exits: <<Unknown>>         
LoopDispositions: { %for.cond: Variant }

Last operand is `%sub.ptr.div`, which is not a pointer, but first operand *is*
So the SCEV has non-pointer type, even though it really should be

Granted, this does not directly matter for expander, it takes extra care
to re-order ops (via LoopCompare) so that pointer operand[s] are first.
But what will happen if we happen to go one layer up, if we happen to be
an expression that has such a mistyped operand? I can't imagine it would handle
it well.

But my main (original) problem with this is that
`ScalarEvolution::getPointerBase()` simply gives up in such cases.

Now, i'm not sure how best to fix this.
I see 3 main paths:
* Teach complexity sorting to partition pointer-typed operands and non-pointer
typed operands.
  I don't believe this is the way, it breaks the entirety of complexity/scev
type grouping.
* Before actually creating SCEVAddExpr, partition operands so that the
non-pointer-ones are first.
  Would this work in general thought? 
* Just store the type in SCEVAddExpr, don't hope that we guess it right.

So, unless i'm missing something obvious, how about we do the latter, and just
store the type?

You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20200625/3ff09b3e/attachment.html>

More information about the llvm-bugs mailing list