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

[via llvm-bugs]

https://bugs.llvm.org/show_bug.cgi?id=46457

            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
works.
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
%sub.ptr.div
  -->  ({((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*
pointer.
So the SCEV has non-pointer type, even though it really should be
pointer-typed.

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
expanding
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>