[llvm-bugs] [Bug 40521] New: Infinite loop in DAG combining

via llvm-bugs llvm-bugs at lists.llvm.org
Wed Jan 30 02:57:33 PST 2019


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

            Bug ID: 40521
           Summary: Infinite loop in DAG combining
           Product: libraries
           Version: trunk
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: Common Code Generator Code
          Assignee: unassignedbugs at nondot.org
          Reporter: mikael.holmen at ericsson.com
                CC: llvm-bugs at lists.llvm.org

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

Reproduce with
 llc bbi-23735.ll -o -

With -debug we see some repeated printouts:

Combining: t28: ch = store<(store 5 into %ir.res2, align 8), trunc to i36>
t126:1, t129, FrameIndex:i64<1>, undef:i64

Combining: t126: i64,ch = load<(dereferenceable load 4 from %ir.f, align 8),
zext from i32> t0, FrameIndex:i64<0>, undef:i64

Combining: t129: i64 = and t127, Constant:i64<4095>
Creating new node: t130: i32 = truncate t126
Creating constant: t131: i32 = Constant<4095>
Creating new node: t132: i32 = srl t130, Constant:i8<15>
Creating new node: t133: i32 = and t132, Constant:i32<4095>
Creating new node: t134: i64 = zero_extend t133
 ... into: t134: i64 = zero_extend t133

Combining: t126: i64,ch = load<(dereferenceable load 4 from %ir.f, align 8),
zext from i32> t0, FrameIndex:i64<0>, undef:i64

Combining: t28: ch = store<(store 5 into %ir.res2, align 8), trunc to i36>
t126:1, t134, FrameIndex:i64<1>, undef:i64

Combining: t134: i64 = zero_extend t133

Combining: t133: i32 = and t132, Constant:i32<4095>

Combining: t131: i32 = Constant<4095>

Combining: t132: i32 = srl t130, Constant:i8<15>

Combining: t130: i32 = truncate t126
Creating new node: t135: i32,ch = load<(dereferenceable load 4 from %ir.f,
align 8)> t0, FrameIndex:i64<0>, undef:i64
 ... into: t135: i32,ch = load<(dereferenceable load 4 from %ir.f, align 8)>
t0, FrameIndex:i64<0>, undef:i64

Combining: t28: ch = store<(store 5 into %ir.res2, align 8), trunc to i36>
t135:1, t134, FrameIndex:i64<1>, undef:i64

Combining: t134: i64 = zero_extend t133
Creating new node: t136: i64,ch = load<(dereferenceable load 4 from %ir.f,
align 8), zext from i32> t0, FrameIndex:i64<0>, undef:i64
Creating new node: t137: i64 = srl t136, Constant:i8<15>
Creating constant: t138: i64 = Constant<4095>
Creating new node: t139: i64 = and t137, Constant:i64<4095>

Replacing.1 t134: i64 = zero_extend t133

With: t139: i64 = and t137, Constant:i64<4095>
 and 0 other values

Combining: t28: ch = store<(store 5 into %ir.res2, align 8), trunc to i36>
t136:1, t139, FrameIndex:i64<1>, undef:i64

Combining: t136: i64,ch = load<(dereferenceable load 4 from %ir.f, align 8),
zext from i32> t0, FrameIndex:i64<0>, undef:i64

Combining: t139: i64 = and t137, Constant:i64<4095>
Creating new node: t140: i32 = truncate t136
Creating constant: t141: i32 = Constant<4095>
Creating new node: t142: i32 = srl t140, Constant:i8<15>
Creating new node: t143: i32 = and t142, Constant:i32<4095>
Creating new node: t144: i64 = zero_extend t143
 ... into: t144: i64 = zero_extend t143

Combining: t136: i64,ch = load<(dereferenceable load 4 from %ir.f, align 8),
zext from i32> t0, FrameIndex:i64<0>, undef:i64

Combining: t28: ch = store<(store 5 into %ir.res2, align 8), trunc to i36>
t136:1, t144, FrameIndex:i64<1>, undef:i64


This starts happening with r329516 but I've no idea if that commit is really to
blame or if it just exposes some old problem.

r329516:
    [DAGCombiner] Fold (zext (and/or/xor (shl/shr (load x), cst), cst))

    In our real world application, we found the following optimization is
missed in DAGCombiner

    (zext (and/or/xor (shl/shr (load x), cst), cst)) -> (and/or/xor (shl/shr
(zextload x), (zext cst)), (zext cst))

    If the user of original zext is an add, it may enable further lea
optimization on x86.

    This patch add a new function CombineZExtLogicopShiftLoad to do this
optimization.

    Differential Revision: https://reviews.llvm.org/D44402

-- 
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/20190130/6b6faddf/attachment-0001.html>


More information about the llvm-bugs mailing list