[llvm-bugs] [Bug 39660] New: Incorrect use-list order is generated due to stale user created when attempting to constant fold

[via llvm-bugs]

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

            Bug ID: 39660
           Summary: Incorrect use-list order is generated due to stale
                    user created when attempting to constant fold
           Product: new-bugs
           Version: trunk
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: new bugs
          Assignee: unassignedbugs at nondot.org
          Reporter: david.stenberg at ericsson.com
                CC: htmldeveloper at gmail.com, llvm-bugs at lists.llvm.org

Created attachment 21119
  --> https://bugs.llvm.org/attachment.cgi?id=21119&action=edit
IR reproducer.

Seen on trunk (r346809).

A run of verify-uselistorder on the attached IR reproducer fails, due to the
use-list order for i64 ptrtoint (i64 ()* @foo to i64) being incorrect.

$ verify-uselistorder reduced.ll -debug 2>&1 | grep -A11 fail:
 - fail: user mismatch: ID = 5
 - LHS value = i64 ptrtoint (i64 ()* @foo to i64)
   => use: op = 0, user-id = 7, user = i64 add (i64 ptrtoint (i64 ()* @foo to
i64), i64 ptrtoint (i64 ()* @foo to i64))
   => use: op = 1, user-id = 7, user = i64 add (i64 ptrtoint (i64 ()* @foo to
i64), i64 ptrtoint (i64 ()* @foo to i64))
   => use: op = 0, user-id = 9, user = i64 add (i64 ptrtoint (i64 ()* @foo to
i64), i64 1)
   => use: op = 0, user-id = 0, user = i64 add (i64 ptrtoint (i64 ()* @foo to
i64), i64 zext (i1 icmp eq (i64 add (i64 ptrtoint (i64 ()* @foo to i64), i64
1), i64 0) to i64))
 - RHS value = i64 ptrtoint (i64 ()* @foo to i64)
   => use: op = 0, user-id = 0, user = i64 add (i64 ptrtoint (i64 ()* @foo to
i64), i64 zext (i1 icmp eq (i64 add (i64 ptrtoint (i64 ()* @foo to i64), i64
1), i64 0) to i64))
   => use: op = 0, user-id = 9, user = i64 add (i64 ptrtoint (i64 ()* @foo to
i64), i64 1)
   => use: op = 1, user-id = 7, user = i64 add (i64 ptrtoint (i64 ()* @foo to
i64), i64 ptrtoint (i64 ()* @foo to i64))
   => use: op = 0, user-id = 7, user = i64 add (i64 ptrtoint (i64 ()* @foo to
i64), i64 ptrtoint (i64 ()* @foo to i64))

If you look in the file, you can see that the following user does not exist:

  user = i64 add (i64 ptrtoint (i64 ()* @foo to i64), i64 zext (i1 icmp eq (i64
add (i64 ptrtoint (i64 ()* @foo to i64), i64 1), i64 0) to i64))

That constant expression is created when parsing:

  i64 add (i64 add (i64 ptrtoint (i64 () * @foo to i64), i64 ptrtoint (i64 () *
@foo to i64)), i64 zext (i1 icmp eq (i64 add (i64 ptrtoint (i64 () * @foo to
i64), i64 1), i64 0) to i64))

That constant expression is attempted to be constant folded by
ConstantFoldBinaryInstruction(), and the new constant expression is created
when attempting to rewrite the outermost add:

  // Given ((a + b) + c), if (b + c) folds to something interesting, return
  // (a + (b + c)).
  if (Instruction::isAssociative(Opcode) && CE1->getOpcode() == Opcode) {
    Constant *T = ConstantExpr::get(Opcode, CE1->getOperand(1), C2);
    if (!isa<ConstantExpr>(T) || cast<ConstantExpr>(T)->getOpcode() != Opcode)
      return ConstantExpr::get(Opcode, CE1->getOperand(0), T);

-- 
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/20181114/3d283e68/attachment-0001.html>