[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