6502/llvm-6502
1
0
Fork 0
mirror of https://github.com/c64scene-ar/llvm-6502.git synced 2024-12-12 13:30:51 +00:00
Code Issues Projects Releases Wiki Activity

Fix PR 8916 (qv for analysis), at least the immediate problem.

Browse Source 
There's an inherent tension in DAGCombine between assuming
that things will be put in canonical form, and the Depth
mechanism that disables transformations when recursion gets
too deep.  It would not surprise me if there's a lot of little
bugs like this one waiting to be discovered.  The mechanism
seems fragile and I'd suggest looking at it from a design viewpoint.



git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@123191 91177308-0d34-0410-b5e6-96231b3b80d8
This commit is contained in:
Dale Johannesen 2011-01-10 21:53:07 +00:00
parent 4a6fb94c40
commit 97fd9a58de
2 changed files with 17 additions and 1 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

3
lib/CodeGen/SelectionDAG/TargetLowering.cpp
View File

@ -1176,8 +1176,9 @@ bool TargetLowering::SimplifyDemandedBits(SDValue Op,
// the RHS.
if (ConstantSDNode *RHSC = dyn_cast<ConstantSDNode>(Op.getOperand(1))) {
APInt LHSZero, LHSOne;
// Do not increment Depth here; that can cause an infinite loop.
TLO.DAG.ComputeMaskedBits(Op.getOperand(0), NewMask,
LHSZero, LHSOne, Depth+1);
LHSZero, LHSOne, Depth);
// If the LHS already has zeros where RHSC does, this and is dead.
if ((LHSZero & NewMask) == (~RHSC->getAPIntValue() & NewMask))
return TLO.CombineTo(Op, Op.getOperand(0));

15
test/CodeGen/X86/2011-01-10-DagCombineHang.ll Normal file
View File

@ -0,0 +1,15 @@
; RUN: llc < %s -mtriple=x86_64-apple-darwin10
; This formerly got DagCombine into a loop, PR 8916.
define i32 @foo(i64 %x, i64 %y, i64 %z, i32 %a, i32 %b) {
entry:
%"alloca point" = bitcast i32 0 to i32 ; <i32> [#uses=0]
%t1 = shl i64 %x, 15
%t2 = and i64 %t1, 4294934528
%t3 = or i64 %t2, %y
%t4 = xor i64 %z, %t3
%t5 = trunc i64 %t4 to i32
%t6 = add i32 %a, %t5
%t7 = add i32 %t6, %b
ret i32 %t7
}