From natebegeman at mac.com Mon Oct 12 00:53:58 2009
From: natebegeman at mac.com (Nate Begeman)
Date: Mon, 12 Oct 2009 05:53:58 -0000
Subject: [llvm-commits] [llvm] r83824 -
/llvm/trunk/lib/CodeGen/SelectionDAG/DAGCombiner.cpp
Message-ID: <200910120553.n9C5rwDF004682@zion.cs.uiuc.edu>
Author: sampo
Date: Mon Oct 12 00:53:58 2009
New Revision: 83824
URL: http://llvm.org/viewvc/llvm-project?rev=83824&view=rev
Log:
More heuristics for Combiner-AA. Still catches all important cases, but
compile time penalty on gnugo, the worst case in MultiSource, is down to
about 2.5% from 30%
Modified:
llvm/trunk/lib/CodeGen/SelectionDAG/DAGCombiner.cpp
Modified: llvm/trunk/lib/CodeGen/SelectionDAG/DAGCombiner.cpp
URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/lib/CodeGen/SelectionDAG/DAGCombiner.cpp?rev=83824&r1=83823&r2=83824&view=diff
==============================================================================
--- llvm/trunk/lib/CodeGen/SelectionDAG/DAGCombiner.cpp (original)
+++ llvm/trunk/lib/CodeGen/SelectionDAG/DAGCombiner.cpp Mon Oct 12 00:53:58 2009
@@ -6230,13 +6230,28 @@
// Starting off.
Chains.push_back(OriginalChain);
-
+ unsigned Depth = 0;
+
// Look at each chain and determine if it is an alias. If so, add it to the
// aliases list. If not, then continue up the chain looking for the next
// candidate.
while (!Chains.empty()) {
SDValue Chain = Chains.back();
Chains.pop_back();
+
+ // For TokenFactor nodes, look at each operand and only continue up the
+ // chain until we find two aliases. If we've seen two aliases, assume we'll
+ // find more and revert to original chain since the xform is unlikely to be
+ // profitable.
+ //
+ // FIXME: The depth check could be made to return the last non-aliasing
+ // chain we found before we hit a tokenfactor rather than the original
+ // chain.
+ if (Depth > 6 || Aliases.size() == 2) {
+ Aliases.clear();
+ Aliases.push_back(OriginalChain);
+ break;
+ }
// Don't bother if we've been before.
if (!Visited.insert(Chain.getNode()))
@@ -6268,8 +6283,7 @@
} else {
// Look further up the chain.
Chains.push_back(Chain.getOperand(0));
- // Clean up old chain.
- AddToWorkList(Chain.getNode());
+ ++Depth;
}
break;
}
@@ -6285,8 +6299,7 @@
}
for (unsigned n = Chain.getNumOperands(); n;)
Chains.push_back(Chain.getOperand(--n));
- // Eliminate the token factor if we can.
- AddToWorkList(Chain.getNode());
+ ++Depth;
break;
default:
@@ -6312,7 +6325,7 @@
// If a single operand then chain to it. We don't need to revisit it.
return Aliases[0];
}
-
+
// Construct a custom tailored token factor.
return DAG.getNode(ISD::TokenFactor, N->getDebugLoc(), MVT::Other,
&Aliases[0], Aliases.size());
From eocallaghan at auroraux.org Mon Oct 12 01:14:06 2009
From: eocallaghan at auroraux.org (Edward O'Callaghan)
Date: Mon, 12 Oct 2009 06:14:06 -0000
Subject: [llvm-commits] [llvm] r83825 - in
/llvm/trunk/test/Transforms/InstCombine:
2004-11-27-SetCCForCastLargerAndConstant.ll
2006-04-28-ShiftShiftLongLong.ll 2008-01-21-MismatchedCastAndCompare.ll
2008-01-21-MulTrunc.ll zext.ll
Message-ID: <200910120614.n9C6E6Gn005360@zion.cs.uiuc.edu>
Author: evocallaghan
Date: Mon Oct 12 01:14:06 2009
New Revision: 83825
URL: http://llvm.org/viewvc/llvm-project?rev=83825&view=rev
Log:
Convert InstCombine tests from notcast to FileCheck.
Modified:
llvm/trunk/test/Transforms/InstCombine/2004-11-27-SetCCForCastLargerAndConstant.ll
llvm/trunk/test/Transforms/InstCombine/2006-04-28-ShiftShiftLongLong.ll
llvm/trunk/test/Transforms/InstCombine/2008-01-21-MismatchedCastAndCompare.ll
llvm/trunk/test/Transforms/InstCombine/2008-01-21-MulTrunc.ll
llvm/trunk/test/Transforms/InstCombine/zext.ll
Modified: llvm/trunk/test/Transforms/InstCombine/2004-11-27-SetCCForCastLargerAndConstant.ll
URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/test/Transforms/InstCombine/2004-11-27-SetCCForCastLargerAndConstant.ll?rev=83825&r1=83824&r2=83825&view=diff
==============================================================================
--- llvm/trunk/test/Transforms/InstCombine/2004-11-27-SetCCForCastLargerAndConstant.ll (original)
+++ llvm/trunk/test/Transforms/InstCombine/2004-11-27-SetCCForCastLargerAndConstant.ll Mon Oct 12 01:14:06 2009
@@ -9,124 +9,152 @@
; be eliminated. In many cases the setCC is also eliminated based on the
; constant value and the range of the casted value.
;
-; RUN: opt < %s -instcombine -S | \
-; RUN: notcast .*int
+; RUN: opt < %s -instcombine -S | FileCheck %s
; END.
define i1 @lt_signed_to_large_unsigned(i8 %SB) {
%Y = sext i8 %SB to i32 ; [#uses=1]
%C = icmp ult i32 %Y, 1024 ; [#uses=1]
ret i1 %C
+; CHECK: %C1 = icmp sgt i8 %SB, -1
+; CHECK: ret i1 %C1
}
define i1 @lt_signed_to_large_signed(i8 %SB) {
%Y = sext i8 %SB to i32 ; [#uses=1]
%C = icmp slt i32 %Y, 1024 ; [#uses=1]
ret i1 %C
+; CHECK: ret i1 true
}
define i1 @lt_signed_to_large_negative(i8 %SB) {
%Y = sext i8 %SB to i32 ; [#uses=1]
%C = icmp slt i32 %Y, -1024 ; [#uses=1]
ret i1 %C
+; CHECK: ret i1 false
}
define i1 @lt_signed_to_small_signed(i8 %SB) {
%Y = sext i8 %SB to i32 ; [#uses=1]
%C = icmp slt i32 %Y, 17 ; [#uses=1]
ret i1 %C
+; CHECK: %C = icmp slt i8 %SB, 17
+; CHECK: ret i1 %C
}
define i1 @lt_signed_to_small_negative(i8 %SB) {
%Y = sext i8 %SB to i32 ; [#uses=1]
%C = icmp slt i32 %Y, -17 ; [#uses=1]
ret i1 %C
+; CHECK: %C = icmp slt i8 %SB, -17
+; CHECK: ret i1 %C
}
define i1 @lt_unsigned_to_large_unsigned(i8 %SB) {
%Y = zext i8 %SB to i32 ; [#uses=1]
%C = icmp ult i32 %Y, 1024 ; [#uses=1]
ret i1 %C
+; CHECK: ret i1 true
}
define i1 @lt_unsigned_to_large_signed(i8 %SB) {
%Y = zext i8 %SB to i32 ; [#uses=1]
%C = icmp slt i32 %Y, 1024 ; [#uses=1]
ret i1 %C
+; CHECK: ret i1 true
}
define i1 @lt_unsigned_to_large_negative(i8 %SB) {
%Y = zext i8 %SB to i32 ; [#uses=1]
%C = icmp slt i32 %Y, -1024 ; [#uses=1]
ret i1 %C
+; CHECK: ret i1 false
}
define i1 @lt_unsigned_to_small_unsigned(i8 %SB) {
%Y = zext i8 %SB to i32 ; [#uses=1]
%C = icmp ult i32 %Y, 17 ; [#uses=1]
ret i1 %C
+; CHECK: %C = icmp ult i8 %SB, 17
+; CHECK: ret i1 %C
}
define i1 @lt_unsigned_to_small_negative(i8 %SB) {
%Y = zext i8 %SB to i32 ; [#uses=1]
%C = icmp slt i32 %Y, -17 ; [#uses=1]
ret i1 %C
+; CHECK: ret i1 false
}
define i1 @gt_signed_to_large_unsigned(i8 %SB) {
%Y = sext i8 %SB to i32 ; [#uses=1]
%C = icmp ugt i32 %Y, 1024 ; [#uses=1]
ret i1 %C
+; CHECK: %C = icmp slt i8 %SB, 0
+; CHECK: ret i1 %C
}
define i1 @gt_signed_to_large_signed(i8 %SB) {
%Y = sext i8 %SB to i32 ; [#uses=1]
%C = icmp sgt i32 %Y, 1024 ; [#uses=1]
ret i1 %C
+; CHECK: ret i1 false
}
define i1 @gt_signed_to_large_negative(i8 %SB) {
%Y = sext i8 %SB to i32 ; [#uses=1]
%C = icmp sgt i32 %Y, -1024 ; [#uses=1]
ret i1 %C
+; CHECK: ret i1 true
}
+
define i1 @gt_signed_to_small_signed(i8 %SB) {
%Y = sext i8 %SB to i32 ; [#uses=1]
%C = icmp sgt i32 %Y, 17 ; [#uses=1]
ret i1 %C
+; CHECK: %C = icmp sgt i8 %SB, 17
+; CHECK: ret i1 %C
}
define i1 @gt_signed_to_small_negative(i8 %SB) {
%Y = sext i8 %SB to i32 ; [#uses=1]
%C = icmp sgt i32 %Y, -17 ; [#uses=1]
ret i1 %C
+; CHECK: %C = icmp sgt i8 %SB, -17
+; CHECK: ret i1 %C
}
define i1 @gt_unsigned_to_large_unsigned(i8 %SB) {
%Y = zext i8 %SB to i32 ; [#uses=1]
%C = icmp ugt i32 %Y, 1024 ; [#uses=1]
ret i1 %C
+; CHECK: ret i1 false
}
define i1 @gt_unsigned_to_large_signed(i8 %SB) {
%Y = zext i8 %SB to i32 ; [#uses=1]
%C = icmp sgt i32 %Y, 1024 ; [#uses=1]
ret i1 %C
+; CHECK: ret i1 false
}
define i1 @gt_unsigned_to_large_negative(i8 %SB) {
%Y = zext i8 %SB to i32 ; [#uses=1]
%C = icmp sgt i32 %Y, -1024 ; [#uses=1]
ret i1 %C
+; CHECK: ret i1 true
}
define i1 @gt_unsigned_to_small_unsigned(i8 %SB) {
%Y = zext i8 %SB to i32 ; [#uses=1]
%C = icmp ugt i32 %Y, 17 ; [#uses=1]
ret i1 %C
+; CHECK: %C = icmp ugt i8 %SB, 17
+; CHECK: ret i1 %C
}
define i1 @gt_unsigned_to_small_negative(i8 %SB) {
%Y = zext i8 %SB to i32 ; [#uses=1]
%C = icmp sgt i32 %Y, -17 ; [#uses=1]
ret i1 %C
+; CHECK: ret i1 true
}
Modified: llvm/trunk/test/Transforms/InstCombine/2006-04-28-ShiftShiftLongLong.ll
URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/test/Transforms/InstCombine/2006-04-28-ShiftShiftLongLong.ll?rev=83825&r1=83824&r2=83825&view=diff
==============================================================================
--- llvm/trunk/test/Transforms/InstCombine/2006-04-28-ShiftShiftLongLong.ll (original)
+++ llvm/trunk/test/Transforms/InstCombine/2006-04-28-ShiftShiftLongLong.ll Mon Oct 12 01:14:06 2009
@@ -1,11 +1,13 @@
-; RUN: opt < %s -instcombine -S | grep shl
-; RUN: opt < %s -instcombine -S | notcast
+; RUN: opt < %s -instcombine -S | FileCheck %s
; This cannot be turned into a sign extending cast!
define i64 @test(i64 %X) {
%Y = shl i64 %X, 16 ; [#uses=1]
+; CHECK: %Y = shl i64 %X, 16
%Z = ashr i64 %Y, 16 ; [#uses=1]
+; CHECK: %Z = ashr i64 %Y, 16
ret i64 %Z
+; CHECK: ret i64 %Z
}
Modified: llvm/trunk/test/Transforms/InstCombine/2008-01-21-MismatchedCastAndCompare.ll
URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/test/Transforms/InstCombine/2008-01-21-MismatchedCastAndCompare.ll?rev=83825&r1=83824&r2=83825&view=diff
==============================================================================
--- llvm/trunk/test/Transforms/InstCombine/2008-01-21-MismatchedCastAndCompare.ll (original)
+++ llvm/trunk/test/Transforms/InstCombine/2008-01-21-MismatchedCastAndCompare.ll Mon Oct 12 01:14:06 2009
@@ -1,5 +1,4 @@
-; RUN: opt < %s -instcombine -S | notcast
-; RUN: opt < %s -instcombine -S | not grep {icmp s}
+; RUN: opt < %s -instcombine -S | FileCheck %s
; PR1940
define i1 @test1(i8 %A, i8 %B) {
@@ -7,6 +6,8 @@
%b = zext i8 %B to i32
%c = icmp sgt i32 %a, %b
ret i1 %c
+; CHECK: %c = icmp ugt i8 %A, %B
+; CHECK: ret i1 %c
}
define i1 @test2(i8 %A, i8 %B) {
@@ -14,4 +15,6 @@
%b = sext i8 %B to i32
%c = icmp ugt i32 %a, %b
ret i1 %c
+; CHECK: %c = icmp ugt i8 %A, %B
+; CHECK: ret i1 %c
}
Modified: llvm/trunk/test/Transforms/InstCombine/2008-01-21-MulTrunc.ll
URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/test/Transforms/InstCombine/2008-01-21-MulTrunc.ll?rev=83825&r1=83824&r2=83825&view=diff
==============================================================================
--- llvm/trunk/test/Transforms/InstCombine/2008-01-21-MulTrunc.ll (original)
+++ llvm/trunk/test/Transforms/InstCombine/2008-01-21-MulTrunc.ll Mon Oct 12 01:14:06 2009
@@ -1,11 +1,15 @@
-; RUN: opt < %s -instcombine -S | notcast
+; RUN: opt < %s -instcombine -S | FileCheck %s
define i16 @test1(i16 %a) {
%tmp = zext i16 %a to i32 ; [#uses=2]
%tmp21 = lshr i32 %tmp, 8 ; [#uses=1]
+; CHECK: %tmp21 = lshr i16 %a, 8
%tmp5 = mul i32 %tmp, 5 ; [#uses=1]
+; CHECK: %tmp5 = mul i16 %a, 5
%tmp.upgrd.32 = or i32 %tmp21, %tmp5 ; [#uses=1]
+; CHECK: %tmp.upgrd.32 = or i16 %tmp21, %tmp5
%tmp.upgrd.3 = trunc i32 %tmp.upgrd.32 to i16 ; [#uses=1]
ret i16 %tmp.upgrd.3
+; CHECK: ret i16 %tmp.upgrd.32
}
Modified: llvm/trunk/test/Transforms/InstCombine/zext.ll
URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/test/Transforms/InstCombine/zext.ll?rev=83825&r1=83824&r2=83825&view=diff
==============================================================================
--- llvm/trunk/test/Transforms/InstCombine/zext.ll (original)
+++ llvm/trunk/test/Transforms/InstCombine/zext.ll Mon Oct 12 01:14:06 2009
@@ -1,11 +1,13 @@
; Tests to make sure elimination of casts is working correctly
-; RUN: opt < %s -instcombine -S | \
-; RUN: notcast {} {%c1.*}
+; RUN: opt < %s -instcombine -S | FileCheck %s
define i64 @test_sext_zext(i16 %A) {
%c1 = zext i16 %A to i32 ; [#uses=1]
%c2 = sext i32 %c1 to i64 ; [#uses=1]
ret i64 %c2
+CHECK-NOT: %c1
+CHECK: %c2 = zext i16 %A to i64
+CHECK: ret i64 %c2
}
; PR3599
@@ -29,5 +31,6 @@
%tmp16 = or i32 %tmp15, %tmp6 ; [#uses=1]
%tmp17 = or i32 %tmp16, %tmp3 ; [#uses=1]
ret i32 %tmp17
+CHECK: ret i1 true
}
From eocallaghan at auroraux.org Mon Oct 12 01:23:57 2009
From: eocallaghan at auroraux.org (Edward O'Callaghan)
Date: Mon, 12 Oct 2009 06:23:57 -0000
Subject: [llvm-commits] [llvm] r83826 - in
/llvm/trunk/test/Transforms/InstCombine: 2003-11-13-ConstExprCastCall.ll
zext.ll
Message-ID: <200910120623.n9C6Nv6c005800@zion.cs.uiuc.edu>
Author: evocallaghan
Date: Mon Oct 12 01:23:56 2009
New Revision: 83826
URL: http://llvm.org/viewvc/llvm-project?rev=83826&view=rev
Log:
Fix syntax error missed in converting zext.ll test. Convert 2003-11-13-ConstExprCastCall.ll to FileCheck from notcast.
Modified:
llvm/trunk/test/Transforms/InstCombine/2003-11-13-ConstExprCastCall.ll
llvm/trunk/test/Transforms/InstCombine/zext.ll
Modified: llvm/trunk/test/Transforms/InstCombine/2003-11-13-ConstExprCastCall.ll
URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/test/Transforms/InstCombine/2003-11-13-ConstExprCastCall.ll?rev=83826&r1=83825&r2=83826&view=diff
==============================================================================
--- llvm/trunk/test/Transforms/InstCombine/2003-11-13-ConstExprCastCall.ll (original)
+++ llvm/trunk/test/Transforms/InstCombine/2003-11-13-ConstExprCastCall.ll Mon Oct 12 01:23:56 2009
@@ -1,8 +1,11 @@
-; RUN: opt < %s -instcombine -S | grep call | notcast
+; RUN: opt < %s -instcombine -S | FileCheck %s
declare void @free(i8*)
define void @test(i32* %X) {
call void (...)* bitcast (void (i8*)* @free to void (...)*)( i32* %X ) ; :1 [#uses=0]
+; CHECK: %tmp = bitcast i32* %X to i8*
+; CHECK: call void @free(i8* %tmp)
ret void
+; CHECK: ret void
}
Modified: llvm/trunk/test/Transforms/InstCombine/zext.ll
URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/test/Transforms/InstCombine/zext.ll?rev=83826&r1=83825&r2=83826&view=diff
==============================================================================
--- llvm/trunk/test/Transforms/InstCombine/zext.ll (original)
+++ llvm/trunk/test/Transforms/InstCombine/zext.ll Mon Oct 12 01:23:56 2009
@@ -5,9 +5,9 @@
%c1 = zext i16 %A to i32 ; [#uses=1]
%c2 = sext i32 %c1 to i64 ; [#uses=1]
ret i64 %c2
-CHECK-NOT: %c1
-CHECK: %c2 = zext i16 %A to i64
-CHECK: ret i64 %c2
+; CHECK-NOT: %c1
+; CHECK: %c2 = zext i16 %A to i64
+; CHECK: ret i64 %c2
}
; PR3599
@@ -31,6 +31,6 @@
%tmp16 = or i32 %tmp15, %tmp6 ; [#uses=1]
%tmp17 = or i32 %tmp16, %tmp3 ; [#uses=1]
ret i32 %tmp17
-CHECK: ret i1 true
+; CHECK: ret i1 true
}
From nicholas at mxc.ca Mon Oct 12 01:32:42 2009
From: nicholas at mxc.ca (Nick Lewycky)
Date: Mon, 12 Oct 2009 06:32:42 -0000
Subject: [llvm-commits] [llvm] r83827 -
/llvm/trunk/test/Transforms/InstCombine/zext.ll
Message-ID: <200910120632.n9C6Wh5l006101@zion.cs.uiuc.edu>
Author: nicholas
Date: Mon Oct 12 01:32:42 2009
New Revision: 83827
URL: http://llvm.org/viewvc/llvm-project?rev=83827&view=rev
Log:
Remove this part of the test, it never actually tested anything anyways. This
unbreaks make check after evocallaghan's changes.
Modified:
llvm/trunk/test/Transforms/InstCombine/zext.ll
Modified: llvm/trunk/test/Transforms/InstCombine/zext.ll
URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/test/Transforms/InstCombine/zext.ll?rev=83827&r1=83826&r2=83827&view=diff
==============================================================================
--- llvm/trunk/test/Transforms/InstCombine/zext.ll (original)
+++ llvm/trunk/test/Transforms/InstCombine/zext.ll Mon Oct 12 01:32:42 2009
@@ -9,28 +9,3 @@
; CHECK: %c2 = zext i16 %A to i64
; CHECK: ret i64 %c2
}
-
-; PR3599
-define i32 @test2(i64 %tmp) nounwind readnone {
-entry:
- %tmp5 = trunc i64 %tmp to i8 ; [#uses=1]
- %tmp7 = lshr i64 %tmp, 8 ; [#uses=1]
- %tmp8 = trunc i64 %tmp7 to i8 ; [#uses=1]
- %tmp10 = lshr i64 %tmp, 16 ; [#uses=1]
- %tmp11 = trunc i64 %tmp10 to i8 ; [#uses=1]
- %tmp13 = lshr i64 %tmp, 24 ; [#uses=1]
- %tmp14 = trunc i64 %tmp13 to i8 ; [#uses=1]
- %tmp1 = zext i8 %tmp5 to i32 ; [#uses=1]
- %tmp2 = zext i8 %tmp8 to i32 ; [#uses=1]
- %tmp3 = shl i32 %tmp2, 8 ; [#uses=1]
- %tmp4 = zext i8 %tmp11 to i32 ; [#uses=1]
- %tmp6 = shl i32 %tmp4, 16 ; [#uses=1]
- %tmp9 = zext i8 %tmp14 to i32 ; [#uses=1]
- %tmp12 = shl i32 %tmp9, 24 ; [#uses=1]
- %tmp15 = or i32 %tmp12, %tmp1 ; [#uses=1]
- %tmp16 = or i32 %tmp15, %tmp6 ; [#uses=1]
- %tmp17 = or i32 %tmp16, %tmp3 ; [#uses=1]
- ret i32 %tmp17
-; CHECK: ret i1 true
-}
-
From eocallaghan at auroraux.org Mon Oct 12 02:18:15 2009
From: eocallaghan at auroraux.org (Edward O'Callaghan)
Date: Mon, 12 Oct 2009 07:18:15 -0000
Subject: [llvm-commits] [llvm] r83828 - in
/llvm/trunk/test/Transforms/InstCombine: IntPtrCast.ll apint-cast.ll
apint-zext1.ll apint-zext2.ll binop-cast.ll cast-mul-select.ll cast-set.ll
cast.ll cast2.ll fpcast.ll
Message-ID: <200910120718.n9C7IFjQ007882@zion.cs.uiuc.edu>
Author: evocallaghan
Date: Mon Oct 12 02:18:14 2009
New Revision: 83828
URL: http://llvm.org/viewvc/llvm-project?rev=83828&view=rev
Log:
Convert the rest of the InstCombine tests from notcast to FileCheck.
Modified:
llvm/trunk/test/Transforms/InstCombine/IntPtrCast.ll
llvm/trunk/test/Transforms/InstCombine/apint-cast.ll
llvm/trunk/test/Transforms/InstCombine/apint-zext1.ll
llvm/trunk/test/Transforms/InstCombine/apint-zext2.ll
llvm/trunk/test/Transforms/InstCombine/binop-cast.ll
llvm/trunk/test/Transforms/InstCombine/cast-mul-select.ll
llvm/trunk/test/Transforms/InstCombine/cast-set.ll
llvm/trunk/test/Transforms/InstCombine/cast.ll
llvm/trunk/test/Transforms/InstCombine/cast2.ll
llvm/trunk/test/Transforms/InstCombine/fpcast.ll
Modified: llvm/trunk/test/Transforms/InstCombine/IntPtrCast.ll
URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/test/Transforms/InstCombine/IntPtrCast.ll?rev=83828&r1=83827&r2=83828&view=diff
==============================================================================
--- llvm/trunk/test/Transforms/InstCombine/IntPtrCast.ll (original)
+++ llvm/trunk/test/Transforms/InstCombine/IntPtrCast.ll Mon Oct 12 02:18:14 2009
@@ -1,9 +1,10 @@
-; RUN: opt < %s -instcombine -S | notcast
+; RUN: opt < %s -instcombine -S | FileCheck %s
target datalayout = "e-p:32:32"
define i32* @test(i32* %P) {
%V = ptrtoint i32* %P to i32 ; [#uses=1]
%P2 = inttoptr i32 %V to i32* ; [#uses=1]
ret i32* %P2
+; CHECK: ret i32* %P
}
Modified: llvm/trunk/test/Transforms/InstCombine/apint-cast.ll
URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/test/Transforms/InstCombine/apint-cast.ll?rev=83828&r1=83827&r2=83828&view=diff
==============================================================================
--- llvm/trunk/test/Transforms/InstCombine/apint-cast.ll (original)
+++ llvm/trunk/test/Transforms/InstCombine/apint-cast.ll Mon Oct 12 02:18:14 2009
@@ -1,20 +1,28 @@
; Tests to make sure elimination of casts is working correctly
-; RUN: opt < %s -instcombine -S | notcast
+; RUN: opt < %s -instcombine -S | FileCheck %s
define i17 @test1(i17 %a) {
%tmp = zext i17 %a to i37 ; [#uses=2]
%tmp21 = lshr i37 %tmp, 8 ; [#uses=1]
+; CHECK: %tmp21 = lshr i17 %a, 8
%tmp5 = shl i37 %tmp, 8 ; [#uses=1]
+; CHECK: %tmp5 = shl i17 %a, 8
%tmp.upgrd.32 = or i37 %tmp21, %tmp5 ; [#uses=1]
+; CHECK: %tmp.upgrd.32 = or i17 %tmp21, %tmp5
%tmp.upgrd.3 = trunc i37 %tmp.upgrd.32 to i17 ; [#uses=1]
ret i17 %tmp.upgrd.3
+; CHECK: ret i17 %tmp.upgrd.32
}
define i167 @test2(i167 %a) {
%tmp = zext i167 %a to i577 ; [#uses=2]
%tmp21 = lshr i577 %tmp, 9 ; [#uses=1]
+; CHECK: %tmp21 = lshr i167 %a, 9
%tmp5 = shl i577 %tmp, 8 ; [#uses=1]
+; CHECK: %tmp5 = shl i167 %a, 8
%tmp.upgrd.32 = or i577 %tmp21, %tmp5 ; [#uses=1]
+; CHECK: %tmp.upgrd.32 = or i167 %tmp21, %tmp5
%tmp.upgrd.3 = trunc i577 %tmp.upgrd.32 to i167 ; [#uses=1]
ret i167 %tmp.upgrd.3
+; CHECK: ret i167 %tmp.upgrd.32
}
Modified: llvm/trunk/test/Transforms/InstCombine/apint-zext1.ll
URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/test/Transforms/InstCombine/apint-zext1.ll?rev=83828&r1=83827&r2=83828&view=diff
==============================================================================
--- llvm/trunk/test/Transforms/InstCombine/apint-zext1.ll (original)
+++ llvm/trunk/test/Transforms/InstCombine/apint-zext1.ll Mon Oct 12 02:18:14 2009
@@ -1,9 +1,11 @@
; Tests to make sure elimination of casts is working correctly
; This test is for Integer BitWidth <= 64 && BitWidth % 2 != 0.
-; RUN: opt < %s -instcombine -S | notcast {} {%c1.*}
+; RUN: opt < %s -instcombine -S | FileCheck %s
define i47 @test_sext_zext(i11 %A) {
%c1 = zext i11 %A to i39
%c2 = sext i39 %c1 to i47
ret i47 %c2
+; CHECK: %c2 = zext i11 %A to i47
+; CHECK: ret i47 %c2
}
Modified: llvm/trunk/test/Transforms/InstCombine/apint-zext2.ll
URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/test/Transforms/InstCombine/apint-zext2.ll?rev=83828&r1=83827&r2=83828&view=diff
==============================================================================
--- llvm/trunk/test/Transforms/InstCombine/apint-zext2.ll (original)
+++ llvm/trunk/test/Transforms/InstCombine/apint-zext2.ll Mon Oct 12 02:18:14 2009
@@ -1,9 +1,11 @@
; Tests to make sure elimination of casts is working correctly
; This test is for Integer BitWidth > 64 && BitWidth <= 1024.
-; RUN: opt < %s -instcombine -S | notcast {} {%c1.*}
+; RUN: opt < %s -instcombine -S | FileCheck %s
define i1024 @test_sext_zext(i77 %A) {
%c1 = zext i77 %A to i533
%c2 = sext i533 %c1 to i1024
ret i1024 %c2
+; CHECK: %c2 = zext i77 %A to i1024
+; CHECK: ret i1024 %c2
}
Modified: llvm/trunk/test/Transforms/InstCombine/binop-cast.ll
URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/test/Transforms/InstCombine/binop-cast.ll?rev=83828&r1=83827&r2=83828&view=diff
==============================================================================
--- llvm/trunk/test/Transforms/InstCombine/binop-cast.ll (original)
+++ llvm/trunk/test/Transforms/InstCombine/binop-cast.ll Mon Oct 12 02:18:14 2009
@@ -1,7 +1,9 @@
-; RUN: opt < %s -instcombine -S | notcast
+; RUN: opt < %s -instcombine -S | FileCheck %s
define i32 @testAdd(i32 %X, i32 %Y) {
%tmp = add i32 %X, %Y
+; CHECK: %tmp = add i32 %X, %Y
%tmp.l = bitcast i32 %tmp to i32
ret i32 %tmp.l
+; CHECK: ret i32 %tmp
}
Modified: llvm/trunk/test/Transforms/InstCombine/cast-mul-select.ll
URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/test/Transforms/InstCombine/cast-mul-select.ll?rev=83828&r1=83827&r2=83828&view=diff
==============================================================================
--- llvm/trunk/test/Transforms/InstCombine/cast-mul-select.ll (original)
+++ llvm/trunk/test/Transforms/InstCombine/cast-mul-select.ll Mon Oct 12 02:18:14 2009
@@ -1,4 +1,4 @@
-; RUN: opt < %s -instcombine -S | notcast
+; RUN: opt < %s -instcombine -S | FileCheck %s
define i32 @mul(i32 %x, i32 %y) {
%A = trunc i32 %x to i8
@@ -6,6 +6,9 @@
%C = mul i8 %A, %B
%D = zext i8 %C to i32
ret i32 %D
+; CHECK: %C = mul i32 %x, %y
+; CHECK: %D = and i32 %C, 255
+; CHECK: ret i32 %D
}
define i32 @select1(i1 %cond, i32 %x, i32 %y, i32 %z) {
@@ -16,6 +19,10 @@
%E = select i1 %cond, i8 %C, i8 %D
%F = zext i8 %E to i32
ret i32 %F
+; CHECK: %D = add i32 %x, %y
+; CHECK: %E = select i1 %cond, i32 %z, i32 %D
+; CHECK: %F = and i32 %E, 255
+; CHECK: ret i32 %F
}
define i8 @select2(i1 %cond, i8 %x, i8 %y, i8 %z) {
@@ -26,4 +33,7 @@
%E = select i1 %cond, i32 %C, i32 %D
%F = trunc i32 %E to i8
ret i8 %F
+; CHECK: %D = add i8 %x, %y
+; CHECK: %E = select i1 %cond, i8 %z, i8 %D
+; CHECK: ret i8 %E
}
Modified: llvm/trunk/test/Transforms/InstCombine/cast-set.ll
URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/test/Transforms/InstCombine/cast-set.ll?rev=83828&r1=83827&r2=83828&view=diff
==============================================================================
--- llvm/trunk/test/Transforms/InstCombine/cast-set.ll (original)
+++ llvm/trunk/test/Transforms/InstCombine/cast-set.ll Mon Oct 12 02:18:14 2009
@@ -1,13 +1,15 @@
; This tests for various complex cast elimination cases instcombine should
; handle.
-; RUN: opt < %s -instcombine -S | notcast
+; RUN: opt < %s -instcombine -S | FileCheck %s
define i1 @test1(i32 %X) {
%A = bitcast i32 %X to i32 ; [#uses=1]
; Convert to setne int %X, 12
%c = icmp ne i32 %A, 12 ; [#uses=1]
ret i1 %c
+; CHECK: %c = icmp ne i32 %X, 12
+; CHECK: ret i1 %c
}
define i1 @test2(i32 %X, i32 %Y) {
@@ -16,6 +18,8 @@
; Convert to setne int %X, %Y
%c = icmp ne i32 %A, %B ; [#uses=1]
ret i1 %c
+; CHECK: %c = icmp ne i32 %X, %Y
+; CHECK: ret i1 %c
}
define i32 @test4(i32 %A) {
@@ -23,6 +27,8 @@
%C = shl i32 %B, 2 ; [#uses=1]
%D = bitcast i32 %C to i32 ; [#uses=1]
ret i32 %D
+; CHECK: %C = shl i32 %A, 2
+; CHECK: ret i32 %C
}
define i16 @test5(i16 %A) {
@@ -30,22 +36,28 @@
%C = and i32 %B, 15 ; [#uses=1]
%D = trunc i32 %C to i16 ; [#uses=1]
ret i16 %D
+; CHECK: %C = and i16 %A, 15
+; CHECK: ret i16 %C
}
define i1 @test6(i1 %A) {
%B = zext i1 %A to i32 ; [#uses=1]
%C = icmp ne i32 %B, 0 ; [#uses=1]
ret i1 %C
+; CHECK: ret i1 %A
}
define i1 @test6a(i1 %A) {
%B = zext i1 %A to i32 ; [#uses=1]
%C = icmp ne i32 %B, -1 ; [#uses=1]
ret i1 %C
+; CHECK: ret i1 true
}
define i1 @test7(i8* %A) {
%B = bitcast i8* %A to i32* ; [#uses=1]
%C = icmp eq i32* %B, null ; [#uses=1]
ret i1 %C
+; CHECK: %C = icmp eq i8* %A, null
+; CHECK: ret i1 %C
}
Modified: llvm/trunk/test/Transforms/InstCombine/cast.ll
URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/test/Transforms/InstCombine/cast.ll?rev=83828&r1=83827&r2=83828&view=diff
==============================================================================
--- llvm/trunk/test/Transforms/InstCombine/cast.ll (original)
+++ llvm/trunk/test/Transforms/InstCombine/cast.ll Mon Oct 12 02:18:14 2009
@@ -1,5 +1,5 @@
; Tests to make sure elimination of casts is working correctly
-; RUN: opt < %s -instcombine -S | grep %c | notcast
+; RUN: opt < %s -instcombine -S | FileCheck %s
@inbuf = external global [32832 x i8] ; <[32832 x i8]*> [#uses=1]
@@ -7,6 +7,7 @@
%c1 = bitcast i32 %A to i32 ; [#uses=1]
%c2 = bitcast i32 %c1 to i32 ; [#uses=1]
ret i32 %c2
+; CHECK: ret i32 %A
}
define i64 @test2(i8 %A) {
@@ -14,6 +15,8 @@
%c2 = zext i16 %c1 to i32 ; [#uses=1]
%Ret = zext i32 %c2 to i64 ; [#uses=1]
ret i64 %Ret
+; CHECK: %Ret = zext i8 %A to i64
+; CHECK: ret i64 %Ret
}
; This function should just use bitwise AND
@@ -21,6 +24,8 @@
%c1 = trunc i64 %A to i8 ; [#uses=1]
%c2 = zext i8 %c1 to i64 ; [#uses=1]
ret i64 %c2
+; CHECK: %c2 = and i64 %A, 255
+; CHECK: ret i64 %c2
}
define i32 @test4(i32 %A, i32 %B) {
@@ -30,6 +35,9 @@
; for the cast elim purpose
%result = zext i8 %c to i32 ; [#uses=1]
ret i32 %result
+; CHECK: %COND = icmp slt i32 %A, %B
+; CHECK: %result = zext i1 %COND to i32
+; CHECK: ret i32 %result
}
define i32 @test5(i1 %B) {
@@ -38,36 +46,46 @@
; this cast
%result = zext i8 %c to i32 ; [#uses=1]
ret i32 %result
+; CHECK: %result = zext i1 %B to i32
+; CHECK: ret i32 %result
}
define i32 @test6(i64 %A) {
%c1 = trunc i64 %A to i32 ; [#uses=1]
%res = bitcast i32 %c1 to i32 ; [#uses=1]
ret i32 %res
+; CHECK: %res = trunc i64 %A to i32
+; CHECK: ret i32 %res
}
define i64 @test7(i1 %A) {
%c1 = zext i1 %A to i32 ; [#uses=1]
%res = sext i32 %c1 to i64 ; [#uses=1]
ret i64 %res
+; CHECK: %res = zext i1 %A to i64
+; CHECK: ret i64 %res
}
define i64 @test8(i8 %A) {
%c1 = sext i8 %A to i64 ; [#uses=1]
%res = bitcast i64 %c1 to i64 ; [#uses=1]
ret i64 %res
+; CHECK: %res = sext i8 %A to i64
+; CHECK: ret i64 %res
}
define i16 @test9(i16 %A) {
%c1 = sext i16 %A to i32 ; [#uses=1]
%c2 = trunc i32 %c1 to i16 ; [#uses=1]
ret i16 %c2
+; CHECK: ret i16 %A
}
define i16 @test10(i16 %A) {
%c1 = sext i16 %A to i32 ; [#uses=1]
%c2 = trunc i32 %c1 to i16 ; [#uses=1]
ret i16 %c2
+; CHECK: ret i16 %A
}
declare void @varargs(i32, ...)
@@ -76,22 +94,31 @@
%c = bitcast i32* %P to i16* ; [#uses=1]
call void (i32, ...)* @varargs( i32 5, i16* %c )
ret void
+; CHECK: call void (i32, ...)* @varargs(i32 5, i32* %P)
+; CHECK: ret void
}
define i32* @test12() {
%p = malloc [4 x i8] ; <[4 x i8]*> [#uses=1]
%c = bitcast [4 x i8]* %p to i32* ; [#uses=1]
ret i32* %c
+; CHECK: %p = malloc i32
+; CHECK: ret i32* %p
}
+
define i8* @test13(i64 %A) {
%c = getelementptr [0 x i8]* bitcast ([32832 x i8]* @inbuf to [0 x i8]*), i64 0, i64 %A ; [#uses=1]
ret i8* %c
+; CHECK: %c = getelementptr [32832 x i8]* @inbuf, i64 0, i64 %A
+; CHECK: ret i8* %c
}
define i1 @test14(i8 %A) {
%c = bitcast i8 %A to i8 ; [#uses=1]
%X = icmp ult i8 %c, -128 ; [#uses=1]
ret i1 %X
+; CHECK: %X = icmp sgt i8 %A, -1
+; CHECK: ret i1 %X
}
@@ -105,24 +132,32 @@
define i1 @test16(i32* %P) {
%c = icmp ne i32* %P, null ; [#uses=1]
ret i1 %c
+; CHECK: %c = icmp ne i32* %P, null
+; CHECK: ret i1 %c
}
define i16 @test17(i1 %tmp3) {
%c = zext i1 %tmp3 to i32 ; [#uses=1]
%t86 = trunc i32 %c to i16 ; [#uses=1]
ret i16 %t86
+; CHECK: %t86 = zext i1 %tmp3 to i16
+; CHECK: ret i16 %t86
}
define i16 @test18(i8 %tmp3) {
%c = sext i8 %tmp3 to i32 ; [#uses=1]
%t86 = trunc i32 %c to i16 ; [#uses=1]
ret i16 %t86
+; CHECK: %t86 = sext i8 %tmp3 to i16
+; CHECK: ret i16 %t86
}
define i1 @test19(i32 %X) {
%c = sext i32 %X to i64 ; [#uses=1]
%Z = icmp slt i64 %c, 12345 ; [#uses=1]
ret i1 %Z
+; CHECK: %Z = icmp slt i32 %X, 12345
+; CHECK: ret i1 %Z
}
define i1 @test20(i1 %B) {
@@ -130,6 +165,7 @@
%D = icmp slt i32 %c, -1 ; [#uses=1]
;; false
ret i1 %D
+; CHECK: ret i1 false
}
define i32 @test21(i32 %X) {
@@ -138,6 +174,8 @@
%c2 = sext i8 %c1 to i32 ; [#uses=1]
%RV = and i32 %c2, 255 ; [#uses=1]
ret i32 %RV
+; CHECK: %c21 = and i32 %X, 255
+; CHECK: ret i32 %c21
}
define i32 @test22(i32 %X) {
@@ -146,6 +184,8 @@
%c2 = sext i8 %c1 to i32 ; [#uses=1]
%RV = shl i32 %c2, 24 ; [#uses=1]
ret i32 %RV
+; CHECK: %RV = shl i32 %X, 24
+; CHECK: ret i32 %RV
}
define i32 @test23(i32 %X) {
@@ -154,6 +194,8 @@
;; and Z are signed.
%c2 = zext i16 %c1 to i32 ; [#uses=1]
ret i32 %c2
+; CHECK: %c2 = and i32 %X, 65535
+; CHECK: ret i32 %c2
}
define i1 @test24(i1 %C) {
@@ -161,6 +203,7 @@
;; Fold cast into select
%c = icmp ne i32 %X, 0 ; [#uses=1]
ret i1 %c
+; CHECK: ret i1 true
}
define void @test25(i32** %P) {
@@ -168,6 +211,8 @@
;; Fold cast into null
store float* null, float** %c
ret void
+; CHECK: store i32* null, i32** %P
+; CHECK: ret void
}
define i32 @test26(float %F) {
@@ -175,16 +220,22 @@
%c = fpext float %F to double ; [#uses=1]
%D = fptosi double %c to i32 ; [#uses=1]
ret i32 %D
+; CHECK: %D = fptosi float %F to i32
+; CHECK: ret i32 %D
}
define [4 x float]* @test27([9 x [4 x float]]* %A) {
%c = bitcast [9 x [4 x float]]* %A to [4 x float]* ; <[4 x float]*> [#uses=1]
ret [4 x float]* %c
+; CHECK: %c = getelementptr inbounds [9 x [4 x float]]* %A, i64 0, i64 0
+; CHECK: ret [4 x float]* %c
}
define float* @test28([4 x float]* %A) {
%c = bitcast [4 x float]* %A to float* ; [#uses=1]
ret float* %c
+; CHECK: %c = getelementptr inbounds [4 x float]* %A, i64 0, i64 0
+; CHECK: ret float* %c
}
define i32 @test29(i32 %c1, i32 %c2) {
@@ -193,6 +244,9 @@
%tmp = or i8 %tmp4.mask, %tmp1 ; [#uses=1]
%tmp10 = zext i8 %tmp to i32 ; [#uses=1]
ret i32 %tmp10
+; CHECK: %tmp2 = or i32 %c2, %c1
+; CHECK: %tmp10 = and i32 %tmp2, 255
+; CHECK: ret i32 %tmp10
}
define i32 @test30(i32 %c1) {
@@ -200,6 +254,9 @@
%c3 = xor i8 %c2, 1 ; [#uses=1]
%c4 = zext i8 %c3 to i32 ; [#uses=1]
ret i32 %c4
+; CHECK: %c3 = and i32 %c1, 255
+; CHECK: %c4 = xor i32 %c3, 1
+; CHECK: ret i32 %c4
}
define i1 @test31(i64 %A) {
@@ -207,6 +264,9 @@
%C = and i32 %B, 42 ; [#uses=1]
%D = icmp eq i32 %C, 10 ; [#uses=1]
ret i1 %D
+; CHECK: %C1 = and i64 %A, 42
+; CHECK: %D = icmp eq i64 %C1, 10
+; CHECK: ret i1 %D
}
define void @test32(double** %tmp) {
@@ -214,12 +274,17 @@
%tmp8.upgrd.1 = bitcast [16 x i8]* %tmp8 to double* ; [#uses=1]
store double* %tmp8.upgrd.1, double** %tmp
ret void
+; CHECK: %tmp81 = malloc [2 x double]
+; CHECK: %tmp81.sub = getelementptr inbounds [2 x double]* %tmp81, i64 0, i64 0
+; CHECK: store double* %tmp81.sub, double** %tmp
+; CHECK: ret void
}
define i32 @test33(i32 %c1) {
%x = bitcast i32 %c1 to float ; [#uses=1]
%y = bitcast float %x to i32 ; [#uses=1]
ret i32 %y
+; CHECK: ret i32 %c1
}
define i16 @test34(i16 %a) {
@@ -227,6 +292,8 @@
%tmp21 = lshr i32 %c1, 8 ; [#uses=1]
%c2 = trunc i32 %tmp21 to i16 ; [#uses=1]
ret i16 %c2
+; CHECK: %tmp21 = lshr i16 %a, 8
+; CHECK: ret i16 %tmp21
}
define i16 @test35(i16 %a) {
@@ -234,6 +301,8 @@
%tmp2 = lshr i16 %c1, 8 ; [#uses=1]
%c2 = bitcast i16 %tmp2 to i16 ; [#uses=1]
ret i16 %c2
+; CHECK: %tmp2 = lshr i16 %a, 8
+; CHECK: ret i16 %tmp2
}
; icmp sgt i32 %a, -1
@@ -243,6 +312,8 @@
%c = trunc i32 %b to i8
%d = icmp eq i8 %c, 0
ret i1 %d
+; CHECK: %d = icmp sgt i32 %a, -1
+; CHECK: ret i1 %d
}
; ret i1 false
@@ -252,6 +323,7 @@
%d = trunc i32 %c to i8
%e = icmp eq i8 %d, 11
ret i1 %e
+; CHECK: ret i1 false
}
define i64 @test38(i32 %a) {
@@ -260,4 +332,7 @@
%3 = xor i8 %2, 1
%4 = zext i8 %3 to i64
ret i64 %4
+; CHECK: %1 = icmp ne i32 %a, -2
+; CHECK: %2 = zext i1 %1 to i64
+; CHECK: ret i64 %2
}
Modified: llvm/trunk/test/Transforms/InstCombine/cast2.ll
URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/test/Transforms/InstCombine/cast2.ll?rev=83828&r1=83827&r2=83828&view=diff
==============================================================================
--- llvm/trunk/test/Transforms/InstCombine/cast2.ll (original)
+++ llvm/trunk/test/Transforms/InstCombine/cast2.ll Mon Oct 12 02:18:14 2009
@@ -1,5 +1,5 @@
; Tests to make sure elimination of casts is working correctly
-; RUN: opt < %s -instcombine -S | notcast
+; RUN: opt < %s -instcombine -S | FileCheck %s
define i16 @test1(i16 %a) {
%tmp = zext i16 %a to i32 ; [#uses=2]
@@ -8,6 +8,8 @@
%tmp.upgrd.32 = or i32 %tmp21, %tmp5 ; [#uses=1]
%tmp.upgrd.3 = trunc i32 %tmp.upgrd.32 to i16 ; [#uses=1]
ret i16 %tmp.upgrd.3
+; CHECK: %tmp.upgrd.32 = call i16 @llvm.bswap.i16(i16 %a)
+; CHECK: ret i16 %tmp.upgrd.32
}
define i16 @test2(i16 %a) {
@@ -17,6 +19,10 @@
%tmp.upgrd.32 = or i32 %tmp21, %tmp5 ; [#uses=1]
%tmp.upgrd.3 = trunc i32 %tmp.upgrd.32 to i16 ; [#uses=1]
ret i16 %tmp.upgrd.3
+; CHECK: %tmp21 = lshr i16 %a, 9
+; CHECK: %tmp5 = shl i16 %a, 8
+; CHECK: %tmp.upgrd.32 = or i16 %tmp21, %tmp5
+; CHECK: ret i16 %tmp.upgrd.32
}
; PR1263
@@ -24,6 +30,7 @@
%tmp64 = bitcast i32* %tmp1 to { i32 }* ; <{ i32 }*> [#uses=1]
%tmp65 = getelementptr { i32 }* %tmp64, i32 0, i32 0 ; [#uses=1]
ret i32* %tmp65
+; CHECK: ret i32* %tmp1
}
Modified: llvm/trunk/test/Transforms/InstCombine/fpcast.ll
URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/test/Transforms/InstCombine/fpcast.ll?rev=83828&r1=83827&r2=83828&view=diff
==============================================================================
--- llvm/trunk/test/Transforms/InstCombine/fpcast.ll (original)
+++ llvm/trunk/test/Transforms/InstCombine/fpcast.ll Mon Oct 12 02:18:14 2009
@@ -1,15 +1,15 @@
; Test some floating point casting cases
-; RUN: opt < %s -instcombine -S | notcast
-; RUN: opt < %s -instcombine -S | \
-; RUN: egrep {ret i8 \(-1\)\|\(255\)}
+; RUN: opt < %s -instcombine -S | FileCheck %s
define i8 @test1() {
%x = fptoui float 2.550000e+02 to i8 ; [#uses=1]
ret i8 %x
+; CHECK: ret i8 -1
}
define i8 @test2() {
%x = fptosi float -1.000000e+00 to i8 ; [#uses=1]
ret i8 %x
+; CHECK: ret i8 -1
}
From anton at korobeynikov.info Mon Oct 12 03:08:02 2009
From: anton at korobeynikov.info (Anton Korobeynikov)
Date: Mon, 12 Oct 2009 12:08:02 +0400
Subject: [llvm-commits] [llvm] r83823 - in /llvm/trunk:
autoconf/configure.ac lib/System/Unix/Process.inc
utils/unittest/googletest/include/gtest/internal/gtest-port.h
In-Reply-To: <200910120457.n9C4vKCL002499@zion.cs.uiuc.edu>
References: <200910120457.n9C4vKCL002499@zion.cs.uiuc.edu>
Message-ID:
> llvm/trunk/autoconf/configure.ac
You need to regenerate configure.
--
With best regards, Anton Korobeynikov
Faculty of Mathematics and Mechanics, Saint Petersburg State University
From baldrick at free.fr Mon Oct 12 03:14:33 2009
From: baldrick at free.fr (Duncan Sands)
Date: Mon, 12 Oct 2009 08:14:33 -0000
Subject: [llvm-commits] [gcc-plugin] r83830 - /gcc-plugin/
Message-ID: <200910120814.n9C8EXQM023130@zion.cs.uiuc.edu>
Author: baldrick
Date: Mon Oct 12 03:14:33 2009
New Revision: 83830
URL: http://llvm.org/viewvc/llvm-project?rev=83830&view=rev
Log:
Rename gcc-plugin to dragonegg.
Removed:
gcc-plugin/
From baldrick at free.fr Mon Oct 12 03:19:49 2009
From: baldrick at free.fr (Duncan Sands)
Date: Mon, 12 Oct 2009 08:19:49 -0000
Subject: [llvm-commits] [gcc-plugin] r83831 - in /gcc-plugin: ./ trunk/
trunk/README
Message-ID: <200910120819.n9C8JnN1023292@zion.cs.uiuc.edu>
Author: baldrick
Date: Mon Oct 12 03:19:49 2009
New Revision: 83831
URL: http://llvm.org/viewvc/llvm-project?rev=83831&view=rev
Log:
Add README explaining that the plugin moved to dragonegg/trunk.
Added:
gcc-plugin/
gcc-plugin/trunk/
gcc-plugin/trunk/README
Added: gcc-plugin/trunk/README
URL: http://llvm.org/viewvc/llvm-project/gcc-plugin/trunk/README?rev=83831&view=auto
==============================================================================
--- gcc-plugin/trunk/README (added)
+++ gcc-plugin/trunk/README Mon Oct 12 03:19:49 2009
@@ -0,0 +1,2 @@
+The gcc plugin has been renamed DragonEgg. You can check it out by doing
+ svn co http://llvm.org/svn/llvm-project/dragonegg/trunk
From eocallaghan at auroraux.org Mon Oct 12 03:46:47 2009
From: eocallaghan at auroraux.org (Edward O'Callaghan)
Date: Mon, 12 Oct 2009 08:46:47 -0000
Subject: [llvm-commits] [llvm] r83833 -
/llvm/trunk/test/Transforms/InstCombine/call.ll
Message-ID: <200910120846.n9C8klCc024223@zion.cs.uiuc.edu>
Author: evocallaghan
Date: Mon Oct 12 03:46:47 2009
New Revision: 83833
URL: http://llvm.org/viewvc/llvm-project?rev=83833&view=rev
Log:
Convert InstCombine/call.ll to CheckFile.
Modified:
llvm/trunk/test/Transforms/InstCombine/call.ll
Modified: llvm/trunk/test/Transforms/InstCombine/call.ll
URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/test/Transforms/InstCombine/call.ll?rev=83833&r1=83832&r2=83833&view=diff
==============================================================================
--- llvm/trunk/test/Transforms/InstCombine/call.ll (original)
+++ llvm/trunk/test/Transforms/InstCombine/call.ll Mon Oct 12 03:46:47 2009
@@ -1,7 +1,5 @@
; Ignore stderr, we expect warnings there
-; RUN: opt < %s -instcombine 2> /dev/null -S | \
-; RUN: grep call | notcast
-; END.
+; RUN: opt < %s -instcombine 2> /dev/null -S | CheckFile %s
; Simple case, argument translatable without changing the value
@@ -10,17 +8,24 @@
define void @test1(i32* %A) {
call void bitcast (void (i8*)* @test1a to void (i32*)*)( i32* %A )
ret void
+; CHECK: %tmp = bitcast i32* %A to i8*
+; CHECK: call void @test1a(i8* %tmp)
+; CHECK: ret void
}
; More complex case, translate argument because of resolution. This is safe
; because we have the body of the function
define void @test2a(i8 %A) {
ret void
+; CHECK: ret void
}
define i32 @test2(i32 %A) {
call void bitcast (void (i8)* @test2a to void (i32)*)( i32 %A )
ret i32 %A
+; CHECK: %tmp = trunc i32 %A to i8
+; CHECK: call void @test2a(i8 %tmp)
+; CHECK: ret i32 %A
}
@@ -32,17 +37,24 @@
call void bitcast (void (i8, ...)* @test3a to void (i8, i8)*)( i8 %A, i8 %B
)
ret void
+; CHECK: %tmp = zext i8 %B to i32
+; CHECK: call void (i8, ...)* @test3a(i8 %A, i32 %tmp)
+; CHECK: ret void
}
; test conversion of return value...
define i8 @test4a() {
ret i8 0
+; CHECK: ret i8 0
}
define i32 @test4() {
%X = call i32 bitcast (i8 ()* @test4a to i32 ()*)( ) ; [#uses=1]
ret i32 %X
+; CHECK: %X1 = call i8 @test4a()
+%tmp = zext i8 %X1 to i32
+ret i32 %tmp
}
@@ -53,6 +65,8 @@
define i32 @test5() {
%X = call i32 @test5a( ) ; [#uses=1]
ret i32 %X
+; CHECK: %X = call i32 @test5a()
+; CHECK: ret i32 %X
}
@@ -62,17 +76,22 @@
define i32 @test6() {
%X = call i32 bitcast (i32 (i32)* @test6a to i32 ()*)( ) ; [#uses=1]
ret i32 %X
+; CHECK: %X1 = call i32 @test6a(i32 0)
+; CHECK: ret i32 %X1
}
; test removal of arguments, only can happen with a function body
define void @test7a() {
ret void
+; CHECK: ret void
}
define void @test7() {
call void bitcast (void ()* @test7a to void (i32)*)( i32 5 )
ret void
+; CHECK: call void @test7a()
+; CHECK: ret void
}
From eocallaghan at auroraux.org Mon Oct 12 03:51:28 2009
From: eocallaghan at auroraux.org (Edward O'Callaghan)
Date: Mon, 12 Oct 2009 08:51:28 -0000
Subject: [llvm-commits] [llvm] r83834 -
/llvm/trunk/test/Transforms/InstCombine/call.ll
Message-ID: <200910120851.n9C8pTW4024386@zion.cs.uiuc.edu>
Author: evocallaghan
Date: Mon Oct 12 03:51:28 2009
New Revision: 83834
URL: http://llvm.org/viewvc/llvm-project?rev=83834&view=rev
Log:
FileCheck not CheckFile, oops.
Modified:
llvm/trunk/test/Transforms/InstCombine/call.ll
Modified: llvm/trunk/test/Transforms/InstCombine/call.ll
URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/test/Transforms/InstCombine/call.ll?rev=83834&r1=83833&r2=83834&view=diff
==============================================================================
--- llvm/trunk/test/Transforms/InstCombine/call.ll (original)
+++ llvm/trunk/test/Transforms/InstCombine/call.ll Mon Oct 12 03:51:28 2009
@@ -1,5 +1,5 @@
; Ignore stderr, we expect warnings there
-; RUN: opt < %s -instcombine 2> /dev/null -S | CheckFile %s
+; RUN: opt < %s -instcombine 2> /dev/null -S | FileCheck %s
; Simple case, argument translatable without changing the value
From eocallaghan at auroraux.org Mon Oct 12 04:01:27 2009
From: eocallaghan at auroraux.org (Edward O'Callaghan)
Date: Mon, 12 Oct 2009 09:01:27 -0000
Subject: [llvm-commits] [llvm] r83835 -
/llvm/trunk/test/Transforms/InstCombine/call.ll
Message-ID: <200910120901.n9C91RA3024770@zion.cs.uiuc.edu>
Author: evocallaghan
Date: Mon Oct 12 04:01:26 2009
New Revision: 83835
URL: http://llvm.org/viewvc/llvm-project?rev=83835&view=rev
Log:
Missing CHECK: lines makes test exit abnormally.
Modified:
llvm/trunk/test/Transforms/InstCombine/call.ll
Modified: llvm/trunk/test/Transforms/InstCombine/call.ll
URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/test/Transforms/InstCombine/call.ll?rev=83835&r1=83834&r2=83835&view=diff
==============================================================================
--- llvm/trunk/test/Transforms/InstCombine/call.ll (original)
+++ llvm/trunk/test/Transforms/InstCombine/call.ll Mon Oct 12 04:01:26 2009
@@ -53,8 +53,8 @@
%X = call i32 bitcast (i8 ()* @test4a to i32 ()*)( ) ; [#uses=1]
ret i32 %X
; CHECK: %X1 = call i8 @test4a()
-%tmp = zext i8 %X1 to i32
-ret i32 %tmp
+; CHECK: %tmp = zext i8 %X1 to i32
+; CHECK: ret i32 %tmp
}
From eocallaghan at auroraux.org Mon Oct 12 04:12:21 2009
From: eocallaghan at auroraux.org (Edward O'Callaghan)
Date: Mon, 12 Oct 2009 10:12:21 +0100
Subject: [llvm-commits] [llvm] r83823 - in /llvm/trunk:
autoconf/configure.ac lib/System/Unix/Process.inc
utils/unittest/googletest/include/gtest/internal/gtest-port.h
In-Reply-To:
References: <200910120457.n9C4vKCL002499@zion.cs.uiuc.edu>
Message-ID: <521640720910120212k507a4735geef739b277059f58@mail.gmail.com>
Oh ! OK thanks, Do you do ./autogen.sh or something?
Maybe quicker if you do it on Linux or what not, results could be not
quite right on my platform?
Cheers,
Edward.
2009/10/12 Anton Korobeynikov :
>> ? ?llvm/trunk/autoconf/configure.ac
> You need to regenerate configure.
>
> --
> With best regards, Anton Korobeynikov
> Faculty of Mathematics and Mechanics, Saint Petersburg State University
>
--
--
Edward O'Callaghan
http://www.auroraux.org/
eocallaghan at auroraux dot org
From benny.kra at googlemail.com Mon Oct 12 04:31:55 2009
From: benny.kra at googlemail.com (Benjamin Kramer)
Date: Mon, 12 Oct 2009 09:31:55 -0000
Subject: [llvm-commits] [llvm] r83837 - in /llvm/trunk/test/CodeGen:
ARM/2009-09-01-PostRAProlog.ll MSP430/Inst16mi.ll MSP430/Inst16mm.ll
MSP430/Inst16mr.ll MSP430/Inst16rm.ll MSP430/Inst16rr.ll MSP430/Inst8mi.ll
MSP430/Inst8mm.ll MSP430/Inst8mr.ll MSP430/Inst8rm.ll MSP430/Inst8rr.ll
SPARC/2009-08-28-PIC.ll SPARC/2009-08-28-WeakLinkage.ll
Message-ID: <200910120931.n9C9VuPD030284@zion.cs.uiuc.edu>
Author: d0k
Date: Mon Oct 12 04:31:55 2009
New Revision: 83837
URL: http://llvm.org/viewvc/llvm-project?rev=83837&view=rev
Log:
Eliminate some redundant llvm-as calls.
Modified:
llvm/trunk/test/CodeGen/ARM/2009-09-01-PostRAProlog.ll
llvm/trunk/test/CodeGen/MSP430/Inst16mi.ll
llvm/trunk/test/CodeGen/MSP430/Inst16mm.ll
llvm/trunk/test/CodeGen/MSP430/Inst16mr.ll
llvm/trunk/test/CodeGen/MSP430/Inst16rm.ll
llvm/trunk/test/CodeGen/MSP430/Inst16rr.ll
llvm/trunk/test/CodeGen/MSP430/Inst8mi.ll
llvm/trunk/test/CodeGen/MSP430/Inst8mm.ll
llvm/trunk/test/CodeGen/MSP430/Inst8mr.ll
llvm/trunk/test/CodeGen/MSP430/Inst8rm.ll
llvm/trunk/test/CodeGen/MSP430/Inst8rr.ll
llvm/trunk/test/CodeGen/SPARC/2009-08-28-PIC.ll
llvm/trunk/test/CodeGen/SPARC/2009-08-28-WeakLinkage.ll
Modified: llvm/trunk/test/CodeGen/ARM/2009-09-01-PostRAProlog.ll
URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/test/CodeGen/ARM/2009-09-01-PostRAProlog.ll?rev=83837&r1=83836&r2=83837&view=diff
==============================================================================
--- llvm/trunk/test/CodeGen/ARM/2009-09-01-PostRAProlog.ll (original)
+++ llvm/trunk/test/CodeGen/ARM/2009-09-01-PostRAProlog.ll Mon Oct 12 04:31:55 2009
@@ -1,4 +1,4 @@
-; RUN: llvm-as < %s | llc -asm-verbose=false -O3 -relocation-model=pic -disable-fp-elim -mtriple=thumbv7-apple-darwin -mcpu=cortex-a8 | FileCheck %s
+; RUN: llc -asm-verbose=false -O3 -relocation-model=pic -disable-fp-elim -mtriple=thumbv7-apple-darwin -mcpu=cortex-a8 < %s | FileCheck %s
target datalayout = "e-p:32:32:32-i1:8:32-i8:8:32-i16:16:32-i32:32:32-i64:32:32-f32:32:32-f64:32:32-v64:64:64-v128:128:128-a0:0:32"
target triple = "thumbv7-apple-darwin9"
Modified: llvm/trunk/test/CodeGen/MSP430/Inst16mi.ll
URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/test/CodeGen/MSP430/Inst16mi.ll?rev=83837&r1=83836&r2=83837&view=diff
==============================================================================
--- llvm/trunk/test/CodeGen/MSP430/Inst16mi.ll (original)
+++ llvm/trunk/test/CodeGen/MSP430/Inst16mi.ll Mon Oct 12 04:31:55 2009
@@ -1,4 +1,4 @@
-; RUN: llvm-as < %s | llc -march=msp430 | FileCheck %s
+; RUN: llc -march=msp430 < %s | FileCheck %s
target datalayout = "e-p:16:8:8-i8:8:8-i16:8:8-i32:8:8"
target triple = "msp430-generic-generic"
Modified: llvm/trunk/test/CodeGen/MSP430/Inst16mm.ll
URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/test/CodeGen/MSP430/Inst16mm.ll?rev=83837&r1=83836&r2=83837&view=diff
==============================================================================
--- llvm/trunk/test/CodeGen/MSP430/Inst16mm.ll (original)
+++ llvm/trunk/test/CodeGen/MSP430/Inst16mm.ll Mon Oct 12 04:31:55 2009
@@ -1,4 +1,4 @@
-; RUN: llvm-as < %s | llc -march=msp430 | FileCheck %s
+; RUN: llc -march=msp430 < %s | FileCheck %s
target datalayout = "e-p:16:8:8-i8:8:8-i16:8:8-i32:8:8"
target triple = "msp430-generic-generic"
@foo = common global i16 0, align 2
Modified: llvm/trunk/test/CodeGen/MSP430/Inst16mr.ll
URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/test/CodeGen/MSP430/Inst16mr.ll?rev=83837&r1=83836&r2=83837&view=diff
==============================================================================
--- llvm/trunk/test/CodeGen/MSP430/Inst16mr.ll (original)
+++ llvm/trunk/test/CodeGen/MSP430/Inst16mr.ll Mon Oct 12 04:31:55 2009
@@ -1,4 +1,4 @@
-; RUN: llvm-as < %s | llc -march=msp430 | FileCheck %s
+; RUN: llc -march=msp430 < %s | FileCheck %s
target datalayout = "e-p:16:8:8-i8:8:8-i16:8:8-i32:8:8"
target triple = "msp430-generic-generic"
@foo = common global i16 0, align 2
Modified: llvm/trunk/test/CodeGen/MSP430/Inst16rm.ll
URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/test/CodeGen/MSP430/Inst16rm.ll?rev=83837&r1=83836&r2=83837&view=diff
==============================================================================
--- llvm/trunk/test/CodeGen/MSP430/Inst16rm.ll (original)
+++ llvm/trunk/test/CodeGen/MSP430/Inst16rm.ll Mon Oct 12 04:31:55 2009
@@ -1,4 +1,4 @@
-; RUN: llvm-as < %s | llc -march=msp430 | FileCheck %s
+; RUN: llc -march=msp430 < %s | FileCheck %s
target datalayout = "e-p:16:8:8-i8:8:8-i16:8:8-i32:8:8"
target triple = "msp430-generic-generic"
@foo = common global i16 0, align 2
Modified: llvm/trunk/test/CodeGen/MSP430/Inst16rr.ll
URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/test/CodeGen/MSP430/Inst16rr.ll?rev=83837&r1=83836&r2=83837&view=diff
==============================================================================
--- llvm/trunk/test/CodeGen/MSP430/Inst16rr.ll (original)
+++ llvm/trunk/test/CodeGen/MSP430/Inst16rr.ll Mon Oct 12 04:31:55 2009
@@ -1,4 +1,4 @@
-; RUN: llvm-as < %s | llc -march=msp430 | FileCheck %s
+; RUN: llc -march=msp430 < %s | FileCheck %s
target datalayout = "e-p:16:8:8-i8:8:8-i16:8:8-i32:8:8"
target triple = "msp430-generic-generic"
Modified: llvm/trunk/test/CodeGen/MSP430/Inst8mi.ll
URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/test/CodeGen/MSP430/Inst8mi.ll?rev=83837&r1=83836&r2=83837&view=diff
==============================================================================
--- llvm/trunk/test/CodeGen/MSP430/Inst8mi.ll (original)
+++ llvm/trunk/test/CodeGen/MSP430/Inst8mi.ll Mon Oct 12 04:31:55 2009
@@ -1,4 +1,4 @@
-; RUN: llvm-as < %s | llc -march=msp430 | FileCheck %s
+; RUN: llc -march=msp430 < %s | FileCheck %s
target datalayout = "e-p:16:8:8-i8:8:8-i8:8:8-i32:8:8"
target triple = "msp430-generic-generic"
@foo = common global i8 0, align 1
Modified: llvm/trunk/test/CodeGen/MSP430/Inst8mm.ll
URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/test/CodeGen/MSP430/Inst8mm.ll?rev=83837&r1=83836&r2=83837&view=diff
==============================================================================
--- llvm/trunk/test/CodeGen/MSP430/Inst8mm.ll (original)
+++ llvm/trunk/test/CodeGen/MSP430/Inst8mm.ll Mon Oct 12 04:31:55 2009
@@ -1,4 +1,4 @@
-; RUN: llvm-as < %s | llc -march=msp430 | FileCheck %s
+; RUN: llc -march=msp430 < %s | FileCheck %s
target datalayout = "e-p:16:8:8-i8:8:8-i16:8:8-i32:8:8"
target triple = "msp430-generic-generic"
Modified: llvm/trunk/test/CodeGen/MSP430/Inst8mr.ll
URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/test/CodeGen/MSP430/Inst8mr.ll?rev=83837&r1=83836&r2=83837&view=diff
==============================================================================
--- llvm/trunk/test/CodeGen/MSP430/Inst8mr.ll (original)
+++ llvm/trunk/test/CodeGen/MSP430/Inst8mr.ll Mon Oct 12 04:31:55 2009
@@ -1,4 +1,4 @@
-; RUN: llvm-as < %s | llc -march=msp430 | FileCheck %s
+; RUN: llc -march=msp430 < %s | FileCheck %s
target datalayout = "e-p:16:8:8-i8:8:8-i16:8:8-i32:8:8"
target triple = "msp430-generic-generic"
@foo = common global i8 0, align 1
Modified: llvm/trunk/test/CodeGen/MSP430/Inst8rm.ll
URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/test/CodeGen/MSP430/Inst8rm.ll?rev=83837&r1=83836&r2=83837&view=diff
==============================================================================
--- llvm/trunk/test/CodeGen/MSP430/Inst8rm.ll (original)
+++ llvm/trunk/test/CodeGen/MSP430/Inst8rm.ll Mon Oct 12 04:31:55 2009
@@ -1,4 +1,4 @@
-; RUN: llvm-as < %s | llc -march=msp430 | FileCheck %s
+; RUN: llc -march=msp430 < %s | FileCheck %s
target datalayout = "e-p:16:8:8-i8:8:8-i8:8:8-i32:8:8"
target triple = "msp430-generic-generic"
@foo = common global i8 0, align 1
Modified: llvm/trunk/test/CodeGen/MSP430/Inst8rr.ll
URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/test/CodeGen/MSP430/Inst8rr.ll?rev=83837&r1=83836&r2=83837&view=diff
==============================================================================
--- llvm/trunk/test/CodeGen/MSP430/Inst8rr.ll (original)
+++ llvm/trunk/test/CodeGen/MSP430/Inst8rr.ll Mon Oct 12 04:31:55 2009
@@ -1,4 +1,4 @@
-; RUN: llvm-as < %s | llc -march=msp430 | FileCheck %s
+; RUN: llc -march=msp430 < %s | FileCheck %s
target datalayout = "e-p:16:8:8-i8:8:8-i8:8:8-i32:8:8"
target triple = "msp430-generic-generic"
Modified: llvm/trunk/test/CodeGen/SPARC/2009-08-28-PIC.ll
URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/test/CodeGen/SPARC/2009-08-28-PIC.ll?rev=83837&r1=83836&r2=83837&view=diff
==============================================================================
--- llvm/trunk/test/CodeGen/SPARC/2009-08-28-PIC.ll (original)
+++ llvm/trunk/test/CodeGen/SPARC/2009-08-28-PIC.ll Mon Oct 12 04:31:55 2009
@@ -1,4 +1,4 @@
-; RUN: llvm-as < %s | llc -march=sparc --relocation-model=pic | grep _GLOBAL_OFFSET_TABLE_
+; RUN: llc -march=sparc --relocation-model=pic < %s | grep _GLOBAL_OFFSET_TABLE_
@foo = global i32 0 ; [#uses=1]
Modified: llvm/trunk/test/CodeGen/SPARC/2009-08-28-WeakLinkage.ll
URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/test/CodeGen/SPARC/2009-08-28-WeakLinkage.ll?rev=83837&r1=83836&r2=83837&view=diff
==============================================================================
--- llvm/trunk/test/CodeGen/SPARC/2009-08-28-WeakLinkage.ll (original)
+++ llvm/trunk/test/CodeGen/SPARC/2009-08-28-WeakLinkage.ll Mon Oct 12 04:31:55 2009
@@ -1,4 +1,4 @@
-; RUN: llvm-as < %s | llc -march=sparc | grep weak
+; RUN: llc -march=sparc < %s | grep weak
define weak i32 @func() nounwind {
entry:
From eocallaghan at auroraux.org Mon Oct 12 06:41:11 2009
From: eocallaghan at auroraux.org (Edward O'Callaghan)
Date: Mon, 12 Oct 2009 12:41:11 +0100
Subject: [llvm-commits] building on haiku fixes
In-Reply-To: <9430ad070909302334n6a5d76a5sbc675931d93c101d@mail.gmail.com>
References: <9430ad070909302324g2b2acaccx3ed4e33769307c5d@mail.gmail.com>
<9430ad070909302334n6a5d76a5sbc675931d93c101d@mail.gmail.com>
Message-ID: <521640720910120441o61de3490we68f81c84d27f2c0@mail.gmail.com>
Applied in Revision: 83823.
In future send patches to the llvmdev mailing list please.
Regards,
Edward.
2009/10/1 Paul Davey :
> this is a patch to make the configure script and a few source fixes to make
> llvm configure and build on haiku
> autoconf/configure.ac
> lib/System/Unix/Process.inc
> utils/unittest/googletest/include/gtest/internal/gtest-port.h
> are the files that have changed,
> it needs the configure script regenerated
>
>
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
>
>
--
--
Edward O'Callaghan
http://www.auroraux.org/
eocallaghan at auroraux dot org
From edwintorok at gmail.com Mon Oct 12 08:37:30 2009
From: edwintorok at gmail.com (Torok Edwin)
Date: Mon, 12 Oct 2009 13:37:30 -0000
Subject: [llvm-commits] [llvm] r83848 - in /llvm/trunk/docs:
ProgrammersManual.html WritingAnLLVMPass.html
Message-ID: <200910121337.n9CDbU2e007164@zion.cs.uiuc.edu>
Author: edwin
Date: Mon Oct 12 08:37:29 2009
New Revision: 83848
URL: http://llvm.org/viewvc/llvm-project?rev=83848&view=rev
Log:
Fix typo, patch from Timo Juhani Lindfors.
Modified:
llvm/trunk/docs/ProgrammersManual.html
llvm/trunk/docs/WritingAnLLVMPass.html
Modified: llvm/trunk/docs/ProgrammersManual.html
URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/docs/ProgrammersManual.html?rev=83848&r1=83847&r2=83848&view=diff
==============================================================================
--- llvm/trunk/docs/ProgrammersManual.html (original)
+++ llvm/trunk/docs/ProgrammersManual.html Mon Oct 12 08:37:29 2009
@@ -3543,7 +3543,7 @@
Value
The Function class represents a single procedure in LLVM. It is
-actually one of the more complex classes in the LLVM heirarchy because it must
+actually one of the more complex classes in the LLVM hierarchy because it must
keep track of a large amount of data. The Function class keeps track
of a list of BasicBlocks, a list of formal
Arguments, and a
Modified: llvm/trunk/docs/WritingAnLLVMPass.html
URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/docs/WritingAnLLVMPass.html?rev=83848&r1=83847&r2=83848&view=diff
==============================================================================
--- llvm/trunk/docs/WritingAnLLVMPass.html (original)
+++ llvm/trunk/docs/WritingAnLLVMPass.html Mon Oct 12 08:37:29 2009
@@ -179,7 +179,7 @@
# Makefile for hello pass
-# Path to top level of LLVM heirarchy
+# Path to top level of LLVM hierarchy
LEVEL = ../../..
# Name of the library to build
From benny.kra at googlemail.com Mon Oct 12 09:46:08 2009
From: benny.kra at googlemail.com (Benjamin Kramer)
Date: Mon, 12 Oct 2009 14:46:08 -0000
Subject: [llvm-commits] [llvm] r83849 - in /llvm/trunk/docs:
BitCodeFormat.html CodingStandards.html CommandLine.html
CompilerDriver.html FAQ.html GetElementPtr.html HowToReleaseLLVM.html
HowToSubmitABug.html LangRef.html LinkTimeOptimization.html
MakefileGuide.html Passes.html ProgrammersManual.html
SourceLevelDebugging.html WritingAnLLVMPass.html tutorial/LangImpl3.html
tutorial/LangImpl4.html tutorial/OCamlLangImpl3.html
tutorial/OCamlLangImpl4.html
Message-ID: <200910121446.n9CEk9PF009954@zion.cs.uiuc.edu>
Author: d0k
Date: Mon Oct 12 09:46:08 2009
New Revision: 83849
URL: http://llvm.org/viewvc/llvm-project?rev=83849&view=rev
Log:
Documentation: Perform automated correction of common typos.
Modified:
llvm/trunk/docs/BitCodeFormat.html
llvm/trunk/docs/CodingStandards.html
llvm/trunk/docs/CommandLine.html
llvm/trunk/docs/CompilerDriver.html
llvm/trunk/docs/FAQ.html
llvm/trunk/docs/GetElementPtr.html
llvm/trunk/docs/HowToReleaseLLVM.html
llvm/trunk/docs/HowToSubmitABug.html
llvm/trunk/docs/LangRef.html
llvm/trunk/docs/LinkTimeOptimization.html
llvm/trunk/docs/MakefileGuide.html
llvm/trunk/docs/Passes.html
llvm/trunk/docs/ProgrammersManual.html
llvm/trunk/docs/SourceLevelDebugging.html
llvm/trunk/docs/WritingAnLLVMPass.html
llvm/trunk/docs/tutorial/LangImpl3.html
llvm/trunk/docs/tutorial/LangImpl4.html
llvm/trunk/docs/tutorial/OCamlLangImpl3.html
llvm/trunk/docs/tutorial/OCamlLangImpl4.html
Modified: llvm/trunk/docs/BitCodeFormat.html
URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/docs/BitCodeFormat.html?rev=83849&r1=83848&r2=83849&view=diff
==============================================================================
--- llvm/trunk/docs/BitCodeFormat.html (original)
+++ llvm/trunk/docs/BitCodeFormat.html Mon Oct 12 09:46:08 2009
@@ -254,7 +254,7 @@
a content-specific id number (for example, LLVM IR uses an ID of 12 to represent
function bodies). Block IDs 0-7 are reserved for standard blocks
whose meaning is defined by Bitcode; block IDs 8 and greater are
-application specific. Nested blocks capture the hierachical structure of the data
+application specific. Nested blocks capture the hierarchical structure of the data
encoded in it, and various properties are associated with blocks as the file is
parsed. Block definitions allow the reader to efficiently skip blocks
in constant time if the reader wants a summary of blocks, or if it wants to
Modified: llvm/trunk/docs/CodingStandards.html
URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/docs/CodingStandards.html?rev=83849&r1=83848&r2=83849&view=diff
==============================================================================
--- llvm/trunk/docs/CodingStandards.html (original)
+++ llvm/trunk/docs/CodingStandards.html Mon Oct 12 09:46:08 2009
@@ -303,7 +303,7 @@
In all cases, prefer spaces to tabs in source files. People have different
-prefered indentation levels, and different styles of indentation that they
+preferred indentation levels, and different styles of indentation that they
like... this is fine. What isn't is that different editors/viewers expand tabs
out to different tab stops. This can cause your code to look completely
unreadable, and it is not worth dealing with.
@@ -491,7 +491,7 @@
must include all of the header files that you are using -- you can
include them either directly
or indirectly (through another header file). To make sure that you don't
-accidently forget to include a header file in your module header, make sure to
+accidentally forget to include a header file in your module header, make sure to
include your module header first in the implementation file (as mentioned
above). This way there won't be any hidden dependencies that you'll find out
about later...
@@ -790,7 +790,7 @@
Use the "assert" function to its fullest. Check all of your
-preconditions and assumptions, you never know when a bug (not neccesarily even
+preconditions and assumptions, you never know when a bug (not necessarily even
yours) might be caught early by an assertion, which reduces debugging time
dramatically. The "<cassert>" header file is probably already
included by the header files you are using, so it doesn't cost anything to use
Modified: llvm/trunk/docs/CommandLine.html
URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/docs/CommandLine.html?rev=83849&r1=83848&r2=83849&view=diff
==============================================================================
--- llvm/trunk/docs/CommandLine.html (original)
+++ llvm/trunk/docs/CommandLine.html Mon Oct 12 09:46:08 2009
@@ -1022,7 +1022,7 @@
code from the storage of the value parsed. For example, lets say that we have a
'-debug' option that we would like to use to enable debug information
across the entire body of our program. In this case, the boolean value
-controlling the debug code should be globally accessable (in a header file, for
+controlling the debug code should be globally accessible (in a header file, for
example) yet the command line option processing code should not be exposed to
all of these clients (requiring lots of .cpp files to #include
CommandLine.h).
@@ -1107,7 +1107,7 @@
example.
The cl::init attribute specifies an
-inital value for a scalar option. If this attribute is
+initial value for a scalar option. If this attribute is
not specified then the command line option value defaults to the value created
by the default constructor for the type. Warning: If you specify both
cl::init and cl::location for an option,
@@ -1178,7 +1178,7 @@
tweak how options are parsed and how --help output is generated to fit
your application well.
-
It is not possible to specify two options from the same catagory (you'll get
+
It is not possible to specify two options from the same category (you'll get
a runtime error) to a single option, except for options in the miscellaneous
-catagory. The CommandLine library specifies defaults for all of these settings
+category. The CommandLine library specifies defaults for all of these settings
that are the most useful in practice and the most common, which mean that you
usually shouldn't have to worry about these.
@@ -1536,7 +1536,7 @@
environment variable to examine, the optional
additional extra text to emit when the
--help option is invoked, and the boolean
-switch that controls whether reponse files
+switch that controls whether response files
should be read.
cl::ParseEnvironmentOptions will break the environment
Modified: llvm/trunk/docs/CompilerDriver.html
URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/docs/CompilerDriver.html?rev=83849&r1=83848&r2=83849&view=diff
==============================================================================
--- llvm/trunk/docs/CompilerDriver.html (original)
+++ llvm/trunk/docs/CompilerDriver.html Mon Oct 12 09:46:08 2009
@@ -307,13 +307,13 @@
-std=c99. It is also allowed to use spaces instead of the equality
sign: -stdc99. At most one occurrence is allowed.
parameter_list_option - same as the above, but more than one option
-occurence is allowed.
+occurrence is allowed.
prefix_option - same as the parameter_option, but the option name and
argument do not have to be separated. Example: -ofile. This can be also
specified as -ofile; however, -o=file will be parsed incorrectly
(=file will be interpreted as option value). At most one occurrence is
allowed.
-
prefix_list_option - same as the above, but more than one occurence of
+
prefix_list_option - same as the above, but more than one occurrence of
the option is allowed; example: -lm-lpthread.
alias_option - a special option type for creating aliases. Unlike other
option types, aliases are not allowed to have any properties besides the
@@ -682,7 +682,7 @@
Mikhail Glushenkov LLVM Compiler Infrastructure
-Last modified: $Date: 2008-12-11 11:34:48 -0600 (Thu, 11 Dec 2008) $
+Last modified: $Date$
Also, there are a number of other limitations of the C backend that cause it
to produce code that does not fully conform to the C++ ABI on most
platforms. Some of the C++ programs in LLVM's test suite are known to fail
- when compiled with the C back end because of ABI incompatiblities with
+ when compiled with the C back end because of ABI incompatibilities with
standard C++ libraries.
@@ -700,7 +700,7 @@
portable is by using the preprocessor to include platform-specific code. In
practice, information about other platforms is lost after preprocessing, so
the result is inherently dependent on the platform that the preprocessing was
- targetting.
+ targeting.
Another example is sizeof. It's common for sizeof(long) to
vary between platforms. In most C front-ends, sizeof is expanded to
Modified: llvm/trunk/docs/GetElementPtr.html
URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/docs/GetElementPtr.html?rev=83849&r1=83848&r2=83849&view=diff
==============================================================================
--- llvm/trunk/docs/GetElementPtr.html (original)
+++ llvm/trunk/docs/GetElementPtr.html Mon Oct 12 09:46:08 2009
@@ -40,7 +40,7 @@
This document seeks to dispel the mystery and confusion surrounding LLVM's
GetElementPtr (GEP) instruction. Questions about the wiley GEP instruction are
- probably the most frequently occuring questions once a developer gets down to
+ probably the most frequently occurring questions once a developer gets down to
coding with LLVM. Here we lay out the sources of confusion and show that the
GEP instruction is really quite simple.
LLVM is released on a time based schedule (currently every 6 months). We
do not have dot releases because of the nature of LLVM incremental
- developement philosophy. The release schedule is roughly as follows:
+ development philosophy. The release schedule is roughly as follows:
Set code freeze and branch creation date for 6 months after last code freeze
@@ -499,7 +499,7 @@
release documentation.
Finally, update the main page (index.html and sidebar) to
point to the new release and release announcement. Make sure this all gets
- commited back into Subversion.
Once you have a reduced test-case, go to the LLVM Bug Tracking
System and fill out the form with the necessary details (note that you don't
-need to pick a catagory, just use the "new-bugs" catagory if you're not sure).
+need to pick a category, just use the "new-bugs" category if you're not sure).
The bug description should contain the following
information:
The string 'undef' can be used anywhere a constant is expected, and
- indicates that the user of the value may recieve an unspecified bit-pattern.
+ indicates that the user of the value may receive an unspecified bit-pattern.
Undefined values may be of any type (other than label or void) and be used
anywhere a constant is permitted.
@@ -2118,7 +2118,7 @@
arbitrarily change its value over its "live range". This is true because the
"variable" doesn't actually have a live range. Instead, the value is
logically read from arbitrary registers that happen to be around when needed,
-so the value is not neccesarily consistent over time. In fact, %A and %C need
+so the value is not necessarily consistent over time. In fact, %A and %C need
to have the same semantics or the core LLVM "replace all uses with" concept
would not hold.
@@ -2300,7 +2300,7 @@
the two digit hex code. For example: "!"test\00"".
Metadata nodes are represented with notation similar to structure constants
- (a comma separated list of elements, surrounded by braces and preceeded by an
+ (a comma separated list of elements, surrounded by braces and preceded by an
exclamation point). For example: "!{ metadata !"test\00", i32
10}".
@@ -2619,8 +2619,8 @@
The switch instruction specifies a table of values and
destinations. When the 'switch' instruction is executed, this table
is searched for the given value. If the value is found, control flow is
- transfered to the corresponding destination; otherwise, control flow is
- transfered to the default destination.
+ transferred to the corresponding destination; otherwise, control flow is
+ transferred to the default destination.
Implementation:
Depending on properties of the target machine and the particular
Modified: llvm/trunk/docs/LinkTimeOptimization.html
URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/docs/LinkTimeOptimization.html?rev=83849&r1=83848&r2=83849&view=diff
==============================================================================
--- llvm/trunk/docs/LinkTimeOptimization.html (original)
+++ llvm/trunk/docs/LinkTimeOptimization.html Mon Oct 12 09:46:08 2009
@@ -166,7 +166,7 @@
provided by the linker on various platform are not unique. This means,
this new tool needs to support all such features and platforms in one
super tool or a separate tool per platform is required. This increases
- maintance cost for link time optimizer significantly, which is not
+ maintenance cost for link time optimizer significantly, which is not
necessary. This approach also requires staying synchronized with linker
developements on various platforms, which is not the main focus of the link
time optimizer. Finally, this approach increases end user's build time due
@@ -189,7 +189,7 @@
user-supplied information, such as a list of exported symbols. LLVM
optimizer collects control flow information, data flow information and knows
much more about program structure from the optimizer's point of view.
- Our goal is to take advantage of tight intergration between the linker and
+ Our goal is to take advantage of tight integration between the linker and
the optimizer by sharing this information during various linking phases.
In some situations, it is desireable to build a single bitcode module from
+
In some situations, it is desirable to build a single bitcode module from
a variety of sources, instead of an archive, shared library, or bitcode
library. Bitcode modules can be specified in addition to any of the other
types of libraries by defining the MODULE_NAME
Modified: llvm/trunk/docs/Passes.html
URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/docs/Passes.html?rev=83849&r1=83848&r2=83849&view=diff
==============================================================================
--- llvm/trunk/docs/Passes.html (original)
+++ llvm/trunk/docs/Passes.html Mon Oct 12 09:46:08 2009
@@ -1544,7 +1544,7 @@
This file demotes all registers to memory references. It is intented to be
the inverse of -mem2reg. By converting to
- load instructions, the only values live accross basic blocks are
+ load instructions, the only values live across basic blocks are
alloca instructions and load instructions before
phi nodes. It is intended that this should make CFG hacking much
easier. To make later hacking easier, the entry block is split into two, such
Modified: llvm/trunk/docs/ProgrammersManual.html
URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/docs/ProgrammersManual.html?rev=83849&r1=83848&r2=83849&view=diff
==============================================================================
--- llvm/trunk/docs/ProgrammersManual.html (original)
+++ llvm/trunk/docs/ProgrammersManual.html Mon Oct 12 09:46:08 2009
@@ -650,7 +650,7 @@
The DEBUG_WITH_TYPE macro is also available for situations where you
would like to set DEBUG_TYPE, but only for one specific DEBUG
statement. It takes an additional first parameter, which is the type to use. For
-example, the preceeding example could be written as:
+example, the preceding example could be written as:
@@ -2983,7 +2983,7 @@
VectorType
Subclass of SequentialType for vector types. A
vector type is similar to an ArrayType but is distinguished because it is
- a first class type wherease ArrayType is not. Vector types are used for
+ a first class type whereas ArrayType is not. Vector types are used for
vector operations and are usually small vectors of of an integer or floating
point type.
StructType
@@ -3552,7 +3552,7 @@
The list of BasicBlocks is the most
commonly used part of Function objects. The list imposes an implicit
ordering of the blocks in the function, which indicate how the code will be
-layed out by the backend. Additionally, the first BasicBlock is the implicit entry node for the
Function. It is not legal in LLVM to explicitly branch to this initial
block. There are no implicit exit nodes, and in fact there may be multiple exit
@@ -3682,7 +3682,7 @@
User,
Value
-
Global variables are represented with the (suprise suprise)
+
Global variables are represented with the (surprise surprise)
GlobalVariable class. Like functions, GlobalVariables are also
subclasses of GlobalValue, and as such are
always referenced by their address (global values must live in memory, so their
@@ -3732,7 +3732,7 @@
Returns the intial value for a GlobalVariable. It is not legal
+
Returns the initial value for a GlobalVariable. It is not legal
to call this method if there is no initializer.
Modified: llvm/trunk/docs/SourceLevelDebugging.html
URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/docs/SourceLevelDebugging.html?rev=83849&r1=83848&r2=83849&view=diff
==============================================================================
--- llvm/trunk/docs/SourceLevelDebugging.html (original)
+++ llvm/trunk/docs/SourceLevelDebugging.html Mon Oct 12 09:46:08 2009
@@ -288,7 +288,7 @@
way. Also, all debugging information objects start with a tag to indicate
what type of object it is. The source-language is allowed to define its own
objects, by using unreserved tag numbers. We recommend using with tags in
- the range 0x1000 thru 0x2000 (there is a defined enum DW_TAG_user_base =
+ the range 0x1000 through 0x2000 (there is a defined enum DW_TAG_user_base =
0x1000.)
The fields of debug descriptors used internally by LLVM
Modified: llvm/trunk/docs/WritingAnLLVMPass.html
URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/docs/WritingAnLLVMPass.html?rev=83849&r1=83848&r2=83849&view=diff
==============================================================================
--- llvm/trunk/docs/WritingAnLLVMPass.html (original)
+++ llvm/trunk/docs/WritingAnLLVMPass.html Mon Oct 12 09:46:08 2009
@@ -453,7 +453,7 @@
When choosing a superclass for your Pass, you should choose the most
specific class possible, while still being able to meet the requirements
listed. This gives the LLVM Pass Infrastructure information necessary to
-optimize how passes are run, so that the resultant compiler isn't unneccesarily
+optimize how passes are run, so that the resultant compiler isn't unnecessarily
slow.
@@ -492,7 +492,7 @@
href="http://llvm.org/doxygen/classllvm_1_1ModulePass.html">ModulePass"
class is the most general of all superclasses that you can use. Deriving from
ModulePass indicates that your pass uses the entire program as a unit,
-refering to function bodies in no predictable order, or adding and removing
+referring to function bodies in no predictable order, or adding and removing
functions. Because nothing is known about the behavior of ModulePass
subclasses, no optimization can be done for their execution.
Modified: llvm/trunk/docs/tutorial/LangImpl3.html
URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/docs/tutorial/LangImpl3.html?rev=83849&r1=83848&r2=83849&view=diff
==============================================================================
--- llvm/trunk/docs/tutorial/LangImpl3.html (original)
+++ llvm/trunk/docs/tutorial/LangImpl3.html Mon Oct 12 09:46:08 2009
@@ -183,7 +183,7 @@
References to variables are also quite simple using LLVM. In the simple version
-of Kaleidoscope, we assume that the variable has already been emited somewhere
+of Kaleidoscope, we assume that the variable has already been emitted somewhere
and its value is available. In practice, the only values that can be in the
NamedValues map are function arguments. This
code simply checks to see that the specified name is in the map (if not, an
@@ -362,7 +362,7 @@
first, we want to allow 'extern'ing a function more than once, as long as the
prototypes for the externs match (since all arguments have the same type, we
just have to check that the number of arguments match). Second, we want to
-allow 'extern'ing a function and then definining a body for it. This is useful
+allow 'extern'ing a function and then defining a body for it. This is useful
when defining mutually recursive functions.
In order to implement this, the code above first checks to see if there is
Modified: llvm/trunk/docs/tutorial/LangImpl4.html
URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/docs/tutorial/LangImpl4.html?rev=83849&r1=83848&r2=83849&view=diff
==============================================================================
--- llvm/trunk/docs/tutorial/LangImpl4.html (original)
+++ llvm/trunk/docs/tutorial/LangImpl4.html Mon Oct 12 09:46:08 2009
@@ -209,7 +209,7 @@
to construct itself. Once it is set up, we use a series of "add" calls to add
a bunch of LLVM passes. The first pass is basically boilerplate, it adds a pass
so that later optimizations know how the data structures in the program are
-layed out. The "TheExecutionEngine" variable is related to the JIT,
+laid out. The "TheExecutionEngine" variable is related to the JIT,
which we will get to in the next section.
In this case, we choose to add 4 optimization passes. The passes we chose
Modified: llvm/trunk/docs/tutorial/OCamlLangImpl3.html
URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/docs/tutorial/OCamlLangImpl3.html?rev=83849&r1=83848&r2=83849&view=diff
==============================================================================
--- llvm/trunk/docs/tutorial/OCamlLangImpl3.html (original)
+++ llvm/trunk/docs/tutorial/OCamlLangImpl3.html Mon Oct 12 09:46:08 2009
@@ -159,7 +159,7 @@
References to variables are also quite simple using LLVM. In the simple
-version of Kaleidoscope, we assume that the variable has already been emited
+version of Kaleidoscope, we assume that the variable has already been emitted
somewhere and its value is available. In practice, the only values that can be
in the Codegen.named_values map are function arguments. This code
simply checks to see that the specified name is in the map (if not, an unknown
@@ -323,7 +323,7 @@
first, we want to allow 'extern'ing a function more than once, as long as the
prototypes for the externs match (since all arguments have the same type, we
just have to check that the number of arguments match). Second, we want to
-allow 'extern'ing a function and then definining a body for it. This is useful
+allow 'extern'ing a function and then defining a body for it. This is useful
when defining mutually recursive functions.
Modified: llvm/trunk/docs/tutorial/OCamlLangImpl4.html
URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/docs/tutorial/OCamlLangImpl4.html?rev=83849&r1=83848&r2=83849&view=diff
==============================================================================
--- llvm/trunk/docs/tutorial/OCamlLangImpl4.html (original)
+++ llvm/trunk/docs/tutorial/OCamlLangImpl4.html Mon Oct 12 09:46:08 2009
@@ -224,7 +224,7 @@
the_module_provider) to construct itself. Once it is set up, we use a
series of "add" calls to add a bunch of LLVM passes. The first pass is
basically boilerplate, it adds a pass so that later optimizations know how the
-data structures in the program are layed out. The
+data structures in the program are laid out. The
"the_execution_engine" variable is related to the JIT, which we will
get to in the next section.
From ggreif at gmail.com Mon Oct 12 11:08:53 2009
From: ggreif at gmail.com (Gabor Greif)
Date: Mon, 12 Oct 2009 16:08:53 -0000
Subject: [llvm-commits] [llvm] r83850 -
/llvm/trunk/docs/ReleaseNotes-2.6.html
Message-ID: <200910121608.n9CG8rBw012920@zion.cs.uiuc.edu>
Author: ggreif
Date: Mon Oct 12 11:08:52 2009
New Revision: 83850
URL: http://llvm.org/viewvc/llvm-project?rev=83850&view=rev
Log:
set some options in typewriter font
Modified:
llvm/trunk/docs/ReleaseNotes-2.6.html
Modified: llvm/trunk/docs/ReleaseNotes-2.6.html
URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/docs/ReleaseNotes-2.6.html?rev=83850&r1=83849&r2=83850&view=diff
==============================================================================
--- llvm/trunk/docs/ReleaseNotes-2.6.html (original)
+++ llvm/trunk/docs/ReleaseNotes-2.6.html Mon Oct 12 11:08:52 2009
@@ -71,6 +71,7 @@
ELF Writer? How stable?
PostRA scheduler improvements, ARM adoption (David Goodwin).
2.7 supports the GDB 7.0 jit interfaces for debug info.
+ 2.7 eliminates ADT/iterator.h
-->
The Llvm.Linkage module is broken, and has incorrect values. Only
-Llvm.Linkage.External, Llvm.Linkage.Available_externally, and
-Llvm.Linkage.Link_once will be correct. If you need any of the other linkage
+
The Llvm.Linkage module is broken, and has incorrect values. Only
+Llvm.Linkage.External, Llvm.Linkage.Available_externally, and
+Llvm.Linkage.Link_once will be correct. If you need any of the other linkage
modes, you'll have to write an external C library in order to expose the
functionality. This has been fixed in the trunk.
From gohman at apple.com Mon Oct 12 11:43:45 2009
From: gohman at apple.com (Dan Gohman)
Date: Mon, 12 Oct 2009 16:43:45 -0000
Subject: [llvm-commits] [llvm] r83856 -
/llvm/trunk/include/llvm/CodeGen/ScheduleDAG.h
Message-ID: <200910121643.n9CGhj4p014161@zion.cs.uiuc.edu>
Author: djg
Date: Mon Oct 12 11:43:44 2009
New Revision: 83856
URL: http://llvm.org/viewvc/llvm-project?rev=83856&view=rev
Log:
Delete some obsolete declarations.
Modified:
llvm/trunk/include/llvm/CodeGen/ScheduleDAG.h
Modified: llvm/trunk/include/llvm/CodeGen/ScheduleDAG.h
URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/include/llvm/CodeGen/ScheduleDAG.h?rev=83856&r1=83855&r2=83856&view=diff
==============================================================================
--- llvm/trunk/include/llvm/CodeGen/ScheduleDAG.h (original)
+++ llvm/trunk/include/llvm/CodeGen/ScheduleDAG.h Mon Oct 12 11:43:44 2009
@@ -518,21 +518,6 @@
void EmitNoop();
void EmitPhysRegCopy(SUnit *SU, DenseMap &VRBaseMap);
-
- private:
- /// EmitLiveInCopy - Emit a copy for a live in physical register. If the
- /// physical register has only a single copy use, then coalesced the copy
- /// if possible.
- void EmitLiveInCopy(MachineBasicBlock *MBB,
- MachineBasicBlock::iterator &InsertPos,
- unsigned VirtReg, unsigned PhysReg,
- const TargetRegisterClass *RC,
- DenseMap &CopyRegMap);
-
- /// EmitLiveInCopies - If this is the first basic block in the function,
- /// and if it has live ins that need to be copied into vregs, emit the
- /// copies into the top of the block.
- void EmitLiveInCopies(MachineBasicBlock *MBB);
};
class SUnitIterator : public std::iterator
Author: djg
Date: Mon Oct 12 11:44:10 2009
New Revision: 83857
URL: http://llvm.org/viewvc/llvm-project?rev=83857&view=rev
Log:
Remove a redundant member variable.
Modified:
llvm/trunk/lib/CodeGen/ScheduleDAGInstrs.h
Modified: llvm/trunk/lib/CodeGen/ScheduleDAGInstrs.h
URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/lib/CodeGen/ScheduleDAGInstrs.h?rev=83857&r1=83856&r2=83857&view=diff
==============================================================================
--- llvm/trunk/lib/CodeGen/ScheduleDAGInstrs.h (original)
+++ llvm/trunk/lib/CodeGen/ScheduleDAGInstrs.h Mon Oct 12 11:44:10 2009
@@ -121,7 +121,6 @@
SmallSet LoopLiveInRegs;
public:
- MachineBasicBlock *BB; // Current basic block
MachineBasicBlock::iterator Begin; // The beginning of the range to
// be scheduled. The range extends
// to InsertPos.
From tonic at nondot.org Mon Oct 12 11:47:02 2009
From: tonic at nondot.org (Tanya Lattner)
Date: Mon, 12 Oct 2009 09:47:02 -0700
Subject: [llvm-commits] [llvm] r83417 -
/llvm/trunk/lib/Support/Triple.cpp
In-Reply-To: <933FB189-6510-469A-9BD9-7151AAD84830@apple.com>
References: <200910062145.n96LjQsf011221@zion.cs.uiuc.edu>
<933FB189-6510-469A-9BD9-7151AAD84830@apple.com>
Message-ID: <645BEEDB-183E-44AB-9F74-48468499FB0A@nondot.org>
Both are merged in.
-Tanya
On Oct 8, 2009, at 11:05 AM, Chris Lattner wrote:
>
> On Oct 8, 2009, at 11:02 AM, Tanya M. Lattner wrote:
>
>>
>> Chris can you approve or deny this patch?
>>
>> Also, are both patches required or just the last one?
>
> yes approved, both patches are required.
>
> -Chris
>
>>
>> Thanks,
>> Tanya
>>
>> On Tue, 6 Oct 2009, Jeffrey Yasskin wrote:
>>
>>> Here's the real twine fix, in case you want it for the 2.6 branch.
>>>
>>> On Tue, Oct 6, 2009 at 2:45 PM, Jeffrey Yasskin
>>> wrote:
>>>> Author: jyasskin
>>>> Date: Tue Oct 6 16:45:26 2009
>>>> New Revision: 83417
>>>>
>>>> URL: http://llvm.org/viewvc/llvm-project?rev=83417&view=rev
>>>> Log:
>>>> r83391 was completely broken since Twines keep references to
>>>> their inputs, and
>>>> some of the inputs were temporaries. Here's a real fix for the
>>>> miscompilation.
>>>> Thanks to sabre for pointing out the problem.
>>>>
>>>> Modified:
>>>> llvm/trunk/lib/Support/Triple.cpp
>>>>
>>>> Modified: llvm/trunk/lib/Support/Triple.cpp
>>>> URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/lib/Support/Triple.cpp?rev=83417&r1=83416&r2=83417&view=diff
>>>>
>>>> =
>>>> =
>>>> =
>>>> =
>>>> =
>>>> =
>>>> =
>>>> =
>>>> =
>>>> =
>>>> =
>>>> ===================================================================
>>>> --- llvm/trunk/lib/Support/Triple.cpp (original)
>>>> +++ llvm/trunk/lib/Support/Triple.cpp Tue Oct 6 16:45:26 2009
>>>> @@ -9,6 +9,7 @@
>>>>
>>>> #include "llvm/ADT/Triple.h"
>>>>
>>>> +#include "llvm/ADT/SmallString.h"
>>>> #include "llvm/ADT/Twine.h"
>>>> #include
>>>> #include
>>>> @@ -390,10 +391,14 @@
>>>> }
>>>>
>>>> void Triple::setArchName(const StringRef &Str) {
>>>> - // Work around a miscompilation bug in gcc 4.0.3.
>>>> - Twine a = getVendorName() + "-" + getOSAndEnvironmentName();
>>>> - Twine b = Str + "-" + a;
>>>> - setTriple(b);
>>>> + // Work around a miscompilation bug for Twines in gcc 4.0.3.
>>>> + SmallString<64> Triple;
>>>> + Triple += Str;
>>>> + Triple += "-";
>>>> + Triple += getVendorName();
>>>> + Triple += "-";
>>>> + Triple += getOSAndEnvironmentName();
>>>> + setTriple(Triple.str());
>>>> }
>>>>
>>>> void Triple::setVendorName(const StringRef &Str) {
>>>>
>>>>
>>>> _______________________________________________
>>>> llvm-commits mailing list
>>>> llvm-commits at cs.uiuc.edu
>>>> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
>>>>
>>>
>> _______________________________________________
>> llvm-commits mailing list
>> llvm-commits at cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
From ggreif at gmail.com Mon Oct 12 11:50:26 2009
From: ggreif at gmail.com (Gabor Greif)
Date: Mon, 12 Oct 2009 16:50:26 -0000
Subject: [llvm-commits] [llvm] r83860 -
/llvm/trunk/docs/ReleaseNotes-2.6.html
Message-ID: <200910121650.n9CGoQps014430@zion.cs.uiuc.edu>
Author: ggreif
Date: Mon Oct 12 11:50:25 2009
New Revision: 83860
URL: http://llvm.org/viewvc/llvm-project?rev=83860&view=rev
Log:
another bunch of s
Modified:
llvm/trunk/docs/ReleaseNotes-2.6.html
Modified: llvm/trunk/docs/ReleaseNotes-2.6.html
URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/docs/ReleaseNotes-2.6.html?rev=83860&r1=83859&r2=83860&view=diff
==============================================================================
--- llvm/trunk/docs/ReleaseNotes-2.6.html (original)
+++ llvm/trunk/docs/ReleaseNotes-2.6.html Mon Oct 12 11:50:25 2009
@@ -796,7 +796,7 @@
New
- PrettyStackTrace classes allows crashes of llvm tools (and applications
+ PrettyStackTrace class allows crashes of llvm tools (and applications
that integrate them) to provide more detailed indication of what the
compiler was doing at the time of the crash (e.g. running a pass).
At the top level for each LLVM tool, it includes the command line arguments.
@@ -804,8 +804,8 @@
New StringRef
and Twine classes
make operations on character ranges and
- string concatenation to be more efficient. StringRef is just a const
- char* with a length, Twine is a light-weight rope.
+ string concatenation to be more efficient. StringRef is just a const
+ char* with a length, Twine is a light-weight rope.
LLVM has new WeakVH, AssertingVH and CallbackVH
classes, which make it easier to write LLVM IR transformations. WeakVH
is automatically drops to null when the referenced Value is deleted,
@@ -889,12 +889,12 @@
The Itanium (IA64) backend has been removed. It was not actively supported
and had bitrotted.
The BigBlock register allocator has been removed, it had also bitrotted.
-
The C Backend (-march=c) is no longer considered part of the LLVM release
+
The C Backend (-march=c) is no longer considered part of the LLVM release
criteria. We still want it to work, but no one is maintaining it and it lacks
support for arbitrary precision integers and other important IR features.
All LLVM tools now default to overwriting their output file, behaving more
- like standard unix tools. Previously, this only happened with the '-f'
+ like standard unix tools. Previously, this only happened with the '-f'
option.
LLVM build now builds all libraries as .a files instead of some
libraries as relinked .o files. This requires some APIs like
@@ -907,11 +907,11 @@
API changes are:
-
All uses of hash_set and hash_map have been removed from the LLVM tree and
- the wrapper headers have been removed.
+
All uses of hash_set and hash_map have been removed from
+ the LLVM tree and the wrapper headers have been removed.
The llvm/Streams.h and DOUT member of Debug.h have been removed. The
llvm::Ostream class has been completely removed and replaced with
- uses of raw_ostream.
+ uses of raw_ostream.
LLVM's global uniquing tables for Types and Constants have
been privatized into members of an LLVMContext. A number of APIs
now take an LLVMContext as a parameter. To smooth the transition
From dpatel at apple.com Mon Oct 12 12:16:15 2009
From: dpatel at apple.com (Devang Patel)
Date: Mon, 12 Oct 2009 10:16:15 -0700
Subject: [llvm-commits] [llvm] r83082 -
/llvm/trunk/include/llvm/ADT/StringRef.h
In-Reply-To: <08828162-224F-46F6-A00A-5C295D19BFE5@apple.com>
References: <200909291839.n8TIdv0K005250@zion.cs.uiuc.edu>
<5EAC33CE-F7F4-415E-AAE2-D3D090178ACB@apple.com>
<9DA16CEF-67EF-449A-870E-9818DA3850CA@apple.com>
<77942D29-5F7E-4AE6-B56B-2CE12FF05A02@apple.com>
<08828162-224F-46F6-A00A-5C295D19BFE5@apple.com>
Message-ID: <3754DE71-073E-4845-9A95-FFF65097080B@apple.com>
OK. I'll update how DebugInfo uses StringRef.
-
Devang
On Oct 12, 2009, at 7:02 AM, Daniel Dunbar wrote:
> Yes, this isn't something that should be in StringRef, I would go so
> far to say this is an invariant clients can rely on:
> --
> StringRef(a).data() == a
> --
>
> As Chris mentions we want the StringRef constructors to be simple,
> we use them a lot and rely on the optimizer to clean them up, for
> example in default arguments. It's good to avoid any unnecessary
> complexity.
>
> - Daniel
>
> On Sep 29, 2009, at 9:59 PM, Chris Lattner wrote:
>
>> On Sep 29, 2009, at 11:57 AM, Devang Patel wrote:
>>> On Sep 29, 2009, at 11:53 AM, Chris Lattner wrote:
>>>> On Sep 29, 2009, at 11:39 AM, Devang Patel wrote:
>>>> Author: dpatel
>>>>> Date: Tue Sep 29 13:39:56 2009
>>>>> New Revision: 83082
>>>>>
>>>>> URL: http://llvm.org/viewvc/llvm-project?rev=83082&view=rev
>>>>> Log:
>>>>> Create empty StringRef is incoming cstring is NULL.
>>>>
>>>> I don't think this is correct, StringRef shouldn't allow null
>>>> cstrings to be passed in.
>>>
>>> I'm using it to pass optional strings. For example, linkage name
>>> in debug info.
>>> Note, one can create empty StringRef by say
>>> SringRef foo;
>>> If this is not desirable then I'll update DebugInfo interface.
>>
>> The reason I mention that is that stringref is frequently used for
>> const char*'s, and this adds an extra branch to the common case.
>> Doing something like:
>>
>> return ptr != 0 : StringRef(ptr) : StringRef();
>>
>> in the debug info stuff would make it pay the cost locally instead
>> of making all clients of stringref pay it.
>>
>> What do you think Daniel?
>>
>> BTW, getting rid of std::string from debug info is really really
>> awesome!
>>
>> -Chris
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/llvm-commits/attachments/20091012/22234047/attachment.html
From jyasskin at google.com Mon Oct 12 12:43:32 2009
From: jyasskin at google.com (Jeffrey Yasskin)
Date: Mon, 12 Oct 2009 17:43:32 -0000
Subject: [llvm-commits] [llvm] r83861 - in /llvm/trunk:
include/llvm/Support/ValueHandle.h lib/VMCore/Value.cpp
unittests/Support/ValueHandleTest.cpp
Message-ID: <200910121743.n9CHhXUc016336@zion.cs.uiuc.edu>
Author: jyasskin
Date: Mon Oct 12 12:43:32 2009
New Revision: 83861
URL: http://llvm.org/viewvc/llvm-project?rev=83861&view=rev
Log:
Fix http://llvm.org/PR5160, to let CallbackVHs modify other ValueHandles on the
same Value without breaking things.
Modified:
llvm/trunk/include/llvm/Support/ValueHandle.h
llvm/trunk/lib/VMCore/Value.cpp
llvm/trunk/unittests/Support/ValueHandleTest.cpp
Modified: llvm/trunk/include/llvm/Support/ValueHandle.h
URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/include/llvm/Support/ValueHandle.h?rev=83861&r1=83860&r2=83861&view=diff
==============================================================================
--- llvm/trunk/include/llvm/Support/ValueHandle.h (original)
+++ llvm/trunk/include/llvm/Support/ValueHandle.h Mon Oct 12 12:43:32 2009
@@ -111,10 +111,15 @@
HandleBaseKind getKind() const { return PrevPair.getInt(); }
void setPrevPtr(ValueHandleBase **Ptr) { PrevPair.setPointer(Ptr); }
- /// AddToExistingUseList - Add this ValueHandle to the use list for VP,
- /// where List is known to point into the existing use list.
+ /// AddToExistingUseList - Add this ValueHandle to the use list for VP, where
+ /// List is the address of either the head of the list or a Next node within
+ /// the existing use list.
void AddToExistingUseList(ValueHandleBase **List);
+ /// AddToExistingUseListAfter - Add this ValueHandle to the use list after
+ /// Node.
+ void AddToExistingUseListAfter(ValueHandleBase *Node);
+
/// AddToUseList - Add this ValueHandle to the use list for VP.
void AddToUseList();
/// RemoveFromUseList - Remove this ValueHandle from its current use list.
Modified: llvm/trunk/lib/VMCore/Value.cpp
URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/lib/VMCore/Value.cpp?rev=83861&r1=83860&r2=83861&view=diff
==============================================================================
--- llvm/trunk/lib/VMCore/Value.cpp (original)
+++ llvm/trunk/lib/VMCore/Value.cpp Mon Oct 12 12:43:32 2009
@@ -411,6 +411,16 @@
}
}
+void ValueHandleBase::AddToExistingUseListAfter(ValueHandleBase *List) {
+ assert(List && "Must insert after existing node");
+
+ Next = List->Next;
+ setPrevPtr(&List->Next);
+ List->Next = this;
+ if (Next)
+ Next->setPrevPtr(&Next);
+}
+
/// AddToUseList - Add this ValueHandle to the use list for VP.
void ValueHandleBase::AddToUseList() {
assert(VP && "Null pointer doesn't have a use list!");
@@ -490,37 +500,46 @@
ValueHandleBase *Entry = pImpl->ValueHandles[V];
assert(Entry && "Value bit set but no entries exist");
- while (Entry) {
- // Advance pointer to avoid invalidation.
- ValueHandleBase *ThisNode = Entry;
- Entry = Entry->Next;
+ // We use a local ValueHandleBase as an iterator so that
+ // ValueHandles can add and remove themselves from the list without
+ // breaking our iteration. This is not really an AssertingVH; we
+ // just have to give ValueHandleBase some kind.
+ for (ValueHandleBase Iterator(Assert, *Entry); Entry; Entry = Iterator.Next) {
+ Iterator.RemoveFromUseList();
+ Iterator.AddToExistingUseListAfter(Entry);
+ assert(Entry->Next == &Iterator && "Loop invariant broken.");
- switch (ThisNode->getKind()) {
+ switch (Entry->getKind()) {
case Assert:
-#ifndef NDEBUG // Only in -g mode...
- errs() << "While deleting: " << *V->getType() << " %" << V->getNameStr()
- << "\n";
-#endif
- llvm_unreachable("An asserting value handle still pointed to this"
- " value!");
+ break;
case Tracking:
// Mark that this value has been deleted by setting it to an invalid Value
// pointer.
- ThisNode->operator=(DenseMapInfo::getTombstoneKey());
+ Entry->operator=(DenseMapInfo::getTombstoneKey());
break;
case Weak:
// Weak just goes to null, which will unlink it from the list.
- ThisNode->operator=(0);
+ Entry->operator=(0);
break;
case Callback:
// Forward to the subclass's implementation.
- static_cast(ThisNode)->deleted();
+ static_cast(Entry)->deleted();
break;
}
}
- // All callbacks and weak references should be dropped by now.
- assert(!V->HasValueHandle && "All references to V were not removed?");
+ // All callbacks, weak references, and assertingVHs should be dropped by now.
+ if (V->HasValueHandle) {
+#ifndef NDEBUG // Only in +Asserts mode...
+ errs() << "While deleting: " << *V->getType() << " %" << V->getNameStr()
+ << "\n";
+ if (pImpl->ValueHandles[V]->getKind() == Assert)
+ llvm_unreachable("An asserting value handle still pointed to this"
+ " value!");
+
+#endif
+ llvm_unreachable("All references to V were not removed?");
+ }
}
@@ -535,12 +554,16 @@
assert(Entry && "Value bit set but no entries exist");
- while (Entry) {
- // Advance pointer to avoid invalidation.
- ValueHandleBase *ThisNode = Entry;
- Entry = Entry->Next;
+ // We use a local ValueHandleBase as an iterator so that
+ // ValueHandles can add and remove themselves from the list without
+ // breaking our iteration. This is not really an AssertingVH; we
+ // just have to give ValueHandleBase some kind.
+ for (ValueHandleBase Iterator(Assert, *Entry); Entry; Entry = Iterator.Next) {
+ Iterator.RemoveFromUseList();
+ Iterator.AddToExistingUseListAfter(Entry);
+ assert(Entry->Next == &Iterator && "Loop invariant broken.");
- switch (ThisNode->getKind()) {
+ switch (Entry->getKind()) {
case Assert:
// Asserting handle does not follow RAUW implicitly.
break;
@@ -553,11 +576,11 @@
// FALLTHROUGH
case Weak:
// Weak goes to the new value, which will unlink it from Old's list.
- ThisNode->operator=(New);
+ Entry->operator=(New);
break;
case Callback:
// Forward to the subclass's implementation.
- static_cast(ThisNode)->allUsesReplacedWith(New);
+ static_cast(Entry)->allUsesReplacedWith(New);
break;
}
}
Modified: llvm/trunk/unittests/Support/ValueHandleTest.cpp
URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/unittests/Support/ValueHandleTest.cpp?rev=83861&r1=83860&r2=83861&view=diff
==============================================================================
--- llvm/trunk/unittests/Support/ValueHandleTest.cpp (original)
+++ llvm/trunk/unittests/Support/ValueHandleTest.cpp Mon Oct 12 12:43:32 2009
@@ -11,6 +11,7 @@
#include "llvm/Constants.h"
#include "llvm/Instructions.h"
+#include "llvm/ADT/OwningPtr.h"
#include "gtest/gtest.h"
@@ -327,4 +328,84 @@
BitcastUser->getOperand(0));
}
+TEST_F(ValueHandle, DestroyingOtherVHOnSameValueDoesntBreakIteration) {
+ // When a CallbackVH modifies other ValueHandles in its callbacks,
+ // that shouldn't interfere with non-modified ValueHandles receiving
+ // their appropriate callbacks.
+ //
+ // We create the active CallbackVH in the middle of a palindromic
+ // arrangement of other VHs so that the bad behavior would be
+ // triggered in whichever order callbacks run.
+
+ class DestroyingVH : public CallbackVH {
+ public:
+ OwningPtr ToClear[2];
+ DestroyingVH(Value *V) {
+ ToClear[0].reset(new WeakVH(V));
+ setValPtr(V);
+ ToClear[1].reset(new WeakVH(V));
+ }
+ virtual void deleted() {
+ ToClear[0].reset();
+ ToClear[1].reset();
+ CallbackVH::deleted();
+ }
+ virtual void allUsesReplacedWith(Value *) {
+ ToClear[0].reset();
+ ToClear[1].reset();
+ }
+ };
+
+ {
+ WeakVH ShouldBeVisited1(BitcastV.get());
+ DestroyingVH C(BitcastV.get());
+ WeakVH ShouldBeVisited2(BitcastV.get());
+
+ BitcastV->replaceAllUsesWith(ConstantV);
+ EXPECT_EQ(ConstantV, static_cast(ShouldBeVisited1));
+ EXPECT_EQ(ConstantV, static_cast(ShouldBeVisited2));
+ }
+
+ {
+ WeakVH ShouldBeVisited1(BitcastV.get());
+ DestroyingVH C(BitcastV.get());
+ WeakVH ShouldBeVisited2(BitcastV.get());
+
+ BitcastV.reset();
+ EXPECT_EQ(NULL, static_cast(ShouldBeVisited1));
+ EXPECT_EQ(NULL, static_cast(ShouldBeVisited2));
+ }
+}
+
+TEST_F(ValueHandle, AssertingVHCheckedLast) {
+ // If a CallbackVH exists to clear out a group of AssertingVHs on
+ // Value deletion, the CallbackVH should get a chance to do so
+ // before the AssertingVHs assert.
+
+ class ClearingVH : public CallbackVH {
+ public:
+ AssertingVH *ToClear[2];
+ ClearingVH(Value *V,
+ AssertingVH &A0, AssertingVH &A1)
+ : CallbackVH(V) {
+ ToClear[0] = &A0;
+ ToClear[1] = &A1;
+ }
+
+ virtual void deleted() {
+ *ToClear[0] = 0;
+ *ToClear[1] = 0;
+ CallbackVH::deleted();
+ }
+ };
+
+ AssertingVH A1, A2;
+ A1 = BitcastV.get();
+ ClearingVH C(BitcastV.get(), A1, A2);
+ A2 = BitcastV.get();
+ // C.deleted() should run first, clearing the two AssertingVHs,
+ // which should prevent them from asserting.
+ BitcastV.reset();
+}
+
}
From natebegeman at mac.com Mon Oct 12 12:58:39 2009
From: natebegeman at mac.com (Nate Begeman)
Date: Mon, 12 Oct 2009 17:58:39 -0000
Subject: [llvm-commits] [test-suite] r83863 -
/test-suite/trunk/Makefile.programs
Message-ID: <200910121758.n9CHwdlP016855@zion.cs.uiuc.edu>
Author: sampo
Date: Mon Oct 12 12:58:38 2009
New Revision: 83863
URL: http://llvm.org/viewvc/llvm-project?rev=83863&view=rev
Log:
Enable combiner-aa as LLCBETA on x86, x86-64 now that (hopefully) final heuristics are in place.
Modified:
test-suite/trunk/Makefile.programs
Modified: test-suite/trunk/Makefile.programs
URL: http://llvm.org/viewvc/llvm-project/test-suite/trunk/Makefile.programs?rev=83863&r1=83862&r2=83863&view=diff
==============================================================================
--- test-suite/trunk/Makefile.programs (original)
+++ test-suite/trunk/Makefile.programs Mon Oct 12 12:58:38 2009
@@ -223,14 +223,14 @@
LLCBETAOPTION := -sched=simple
endif
ifeq ($(ARCH),x86_64)
-LLCBETAOPTION := -remat-pic-stub-load
+LLCBETAOPTION := -combiner-alias-analysis
#-pre-alloc-split
-#-combiner-alias-analysis
+#-remat-pic-stub-load
endif
ifeq ($(ARCH),x86)
-LLCBETAOPTION := -remat-pic-stub-load
+LLCBETAOPTION := -combiner-alias-analysis
#-pre-alloc-split
-#-combiner-alias-analysis
+#-remat-pic-stub-load
#-combiner-global-alias-analysis
#-fast-isel
#-new-spilling-heuristic
From sabre at nondot.org Mon Oct 12 13:12:47 2009
From: sabre at nondot.org (Chris Lattner)
Date: Mon, 12 Oct 2009 18:12:47 -0000
Subject: [llvm-commits] [llvm] r83865 - /llvm/trunk/docs/Bugpoint.html
Message-ID: <200910121812.n9CIClmC017548@zion.cs.uiuc.edu>
Author: lattner
Date: Mon Oct 12 13:12:47 2009
New Revision: 83865
URL: http://llvm.org/viewvc/llvm-project?rev=83865&view=rev
Log:
Improve bugpoint doc, patch by Timo Lindfors!
Modified:
llvm/trunk/docs/Bugpoint.html
Modified: llvm/trunk/docs/Bugpoint.html
URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/docs/Bugpoint.html?rev=83865&r1=83864&r2=83865&view=diff
==============================================================================
--- llvm/trunk/docs/Bugpoint.html (original)
+++ llvm/trunk/docs/Bugpoint.html Mon Oct 12 13:12:47 2009
@@ -216,6 +216,17 @@
the list of specified optimizations to be randomized and applied to the
program. This process will repeat until a bug is found or the user
kills bugpoint.
+
+
bugpoint does not understand the -O option
+ that is used to specify optimization level to opt. You
+ can use e.g.
to get a list of passes that are used with -O2 and
+ then pass this list to bugpoint.
From sabre at nondot.org Mon Oct 12 13:33:33 2009
From: sabre at nondot.org (Chris Lattner)
Date: Mon, 12 Oct 2009 18:33:33 -0000
Subject: [llvm-commits] [llvm] r83868 -
/llvm/trunk/docs/ReleaseNotes-2.6.html
Message-ID: <200910121833.n9CIXX2K018483@zion.cs.uiuc.edu>
Author: lattner
Date: Mon Oct 12 13:33:33 2009
New Revision: 83868
URL: http://llvm.org/viewvc/llvm-project?rev=83868&view=rev
Log:
fix validation error pointed out by gabor (and the w3c :)
Modified:
llvm/trunk/docs/ReleaseNotes-2.6.html
Modified: llvm/trunk/docs/ReleaseNotes-2.6.html
URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/docs/ReleaseNotes-2.6.html?rev=83868&r1=83867&r2=83868&view=diff
==============================================================================
--- llvm/trunk/docs/ReleaseNotes-2.6.html (original)
+++ llvm/trunk/docs/ReleaseNotes-2.6.html Mon Oct 12 13:33:33 2009
@@ -754,13 +754,13 @@
The ARM calling convention code is now tblgen generated instead of resorting
to C++ code.
+
These features are still somewhat experimental
and subject to change. The Neon intrinsics, in particular, may change in future
releases of LLVM. ARMv7 support has progressed a lot on top of tree since 2.6
branched.
-
From dalej at apple.com Mon Oct 12 13:33:50 2009
From: dalej at apple.com (Dale Johannesen)
Date: Mon, 12 Oct 2009 11:33:50 -0700
Subject: [llvm-commits] [llvm] r83675 - in /llvm/trunk:
include/llvm/Transforms/Utils/InlineCost.h
lib/Transforms/IPO/Inliner.cpp lib/Transforms/Utils/InlineCost.cpp
In-Reply-To: <6a8523d60910101242q478a1fcfl311f4a9d673495e0@mail.gmail.com>
References: <200910092142.n99Lg3nh004433@zion.cs.uiuc.edu>
<6a8523d60910101242q478a1fcfl311f4a9d673495e0@mail.gmail.com>
Message-ID:
On Oct 10, 2009, at 12:42 PMPDT, Daniel Dunbar wrote:
>>
>> + namespace InlineConstants {
>> + // Various magic constants used to adjust heuristics.
>> + const int CallPenalty = 5;
>> + const int LastCallToStaticBonus = -15000;
>
> Seems strange to call this a "Bonus", but have a the negative value be
> the "bonus". Wouldn't it make more sense to name it penalty as well?
> Or perhaps replace {Penalty,Bonus} with a more neutral word like Cost?
These numbers are used to compute a Cost. Penalties increase the
cost. Bonuses decrease it. I do find it mildly confusing to have
negative values mean more inlining; I wouldn't have done it that way,
but I can live with it.
From nlewycky at google.com Mon Oct 12 13:44:58 2009
From: nlewycky at google.com (Nick Lewycky)
Date: Mon, 12 Oct 2009 11:44:58 -0700
Subject: [llvm-commits] patch: memory use markers
In-Reply-To: <19D8DF80-620E-41D0-915D-A3D505766B00@apple.com>
References: <4AD25B50.4000008@mxc.ca>
<19D8DF80-620E-41D0-915D-A3D505766B00@apple.com>
Message-ID:
2009/10/12 Dan Gohman
>
> On Oct 11, 2009, at 3:25 PM, Nick Lewycky wrote:
>
> > This patch adds memory use markers as described in
> http://nondot.org/sabre/LLVMNotes/MemoryUseMarkers.txt
> > . The bulk of the patch makes it possible to have intrinsics which
> > return {}.
>
> Hi Nick,
>
> The use of {} here is clever, but I don't think it's correct. Since {}
> has
> no members, the set of values has exactly one element, which means
> that all values of type {} can be assumed to be equivalent. Please use
> something like opaque* instead.
>
I brought that up with Chris much earlier on (since I would've had this
patch done a month ago were it not for the need to support {}) but he was
adamant that {} was the correct type for these. I was suggesting metadata
type though; opaque types require a name in the module.
With @llvm.invariant.end being marked readonly and nounwind, and having
> a void return type, it would seem to be trivially dead everywhere.
> Should
> the readonly be removed?
>
Good catch! Does this rule apply to intrinsics as well? How does
@llvm.gcread work? I will check on it and make sure we're doing the right
thing here.
Nick
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/llvm-commits/attachments/20091012/83a7a800/attachment.html
From dalej at apple.com Mon Oct 12 13:45:32 2009
From: dalej at apple.com (Dale Johannesen)
Date: Mon, 12 Oct 2009 18:45:32 -0000
Subject: [llvm-commits] [llvm] r83870 -
/llvm/trunk/lib/Transforms/Scalar/InstructionCombining.cpp
Message-ID: <200910121845.n9CIjXhD019004@zion.cs.uiuc.edu>
Author: johannes
Date: Mon Oct 12 13:45:32 2009
New Revision: 83870
URL: http://llvm.org/viewvc/llvm-project?rev=83870&view=rev
Log:
Fix warning.
Modified:
llvm/trunk/lib/Transforms/Scalar/InstructionCombining.cpp
Modified: llvm/trunk/lib/Transforms/Scalar/InstructionCombining.cpp
URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/lib/Transforms/Scalar/InstructionCombining.cpp?rev=83870&r1=83869&r2=83870&view=diff
==============================================================================
--- llvm/trunk/lib/Transforms/Scalar/InstructionCombining.cpp (original)
+++ llvm/trunk/lib/Transforms/Scalar/InstructionCombining.cpp Mon Oct 12 13:45:32 2009
@@ -2824,7 +2824,7 @@
// X * Y (where Y is 0 or 1) -> X & (0-Y)
if (!isa(I.getType())) {
// -2 is "-1 << 1" so it is all bits set except the low one.
- APInt Negative2(I.getType()->getPrimitiveSizeInBits(), -2, true);
+ APInt Negative2(I.getType()->getPrimitiveSizeInBits(), (uint64_t)-2, true);
Value *BoolCast = 0, *OtherOp = 0;
if (MaskedValueIsZero(Op0, Negative2))
From dalej at apple.com Mon Oct 12 13:49:00 2009
From: dalej at apple.com (Dale Johannesen)
Date: Mon, 12 Oct 2009 18:49:00 -0000
Subject: [llvm-commits] [llvm] r83871 - in /llvm/trunk:
include/llvm/Target/TargetInstrInfo.h lib/CodeGen/TargetInstrInfoImpl.cpp
lib/CodeGen/VirtRegRewriter.cpp lib/Target/PowerPC/PPCInstrInfo.h
Message-ID: <200910121849.n9CIn0VK019156@zion.cs.uiuc.edu>
Author: johannes
Date: Mon Oct 12 13:49:00 2009
New Revision: 83871
URL: http://llvm.org/viewvc/llvm-project?rev=83871&view=rev
Log:
Revert the kludge in 76703. I got a clean
bootstrap of FSF-style PPC, so there is some
reason to believe the original bug (which was
never analyzed) has been fixed, probably by
82266.
Modified:
llvm/trunk/include/llvm/Target/TargetInstrInfo.h
llvm/trunk/lib/CodeGen/TargetInstrInfoImpl.cpp
llvm/trunk/lib/CodeGen/VirtRegRewriter.cpp
llvm/trunk/lib/Target/PowerPC/PPCInstrInfo.h
Modified: llvm/trunk/include/llvm/Target/TargetInstrInfo.h
URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/include/llvm/Target/TargetInstrInfo.h?rev=83871&r1=83870&r2=83871&view=diff
==============================================================================
--- llvm/trunk/include/llvm/Target/TargetInstrInfo.h (original)
+++ llvm/trunk/include/llvm/Target/TargetInstrInfo.h Mon Oct 12 13:49:00 2009
@@ -449,10 +449,6 @@
return true;
}
- /// isDeadInstruction - Return true if the instruction is considered dead.
- /// This allows some late codegen passes to delete them.
- virtual bool isDeadInstruction(const MachineInstr *MI) const = 0;
-
/// GetInstSize - Returns the size of the specified Instruction.
///
virtual unsigned GetInstSizeInBytes(const MachineInstr *MI) const {
@@ -490,8 +486,6 @@
MachineBasicBlock::iterator MI,
unsigned DestReg, unsigned SubReg,
const MachineInstr *Orig) const;
- virtual bool isDeadInstruction(const MachineInstr *MI) const;
-
virtual unsigned GetFunctionSizeInBytes(const MachineFunction &MF) const;
};
Modified: llvm/trunk/lib/CodeGen/TargetInstrInfoImpl.cpp
URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/lib/CodeGen/TargetInstrInfoImpl.cpp?rev=83871&r1=83870&r2=83871&view=diff
==============================================================================
--- llvm/trunk/lib/CodeGen/TargetInstrInfoImpl.cpp (original)
+++ llvm/trunk/lib/CodeGen/TargetInstrInfoImpl.cpp Mon Oct 12 13:49:00 2009
@@ -143,27 +143,6 @@
MBB.insert(I, MI);
}
-bool TargetInstrInfoImpl::isDeadInstruction(const MachineInstr *MI) const {
- const TargetInstrDesc &TID = MI->getDesc();
- if (TID.mayLoad() || TID.mayStore() || TID.isCall() || TID.isTerminator() ||
- TID.isCall() || TID.isBarrier() || TID.isReturn() ||
- TID.hasUnmodeledSideEffects())
- return false;
- for (unsigned i = 0, e = MI->getNumOperands(); i != e; ++i) {
- const MachineOperand &MO = MI->getOperand(i);
- if (!MO.isReg() || !MO.getReg())
- continue;
- if (MO.isDef() && !MO.isDead())
- return false;
- if (MO.isUse() && MO.isKill())
- // FIXME: We can't remove kill markers or else the scavenger will assert.
- // An alternative is to add a ADD pseudo instruction to replace kill
- // markers.
- return false;
- }
- return true;
-}
-
unsigned
TargetInstrInfoImpl::GetFunctionSizeInBytes(const MachineFunction &MF) const {
unsigned FnSize = 0;
Modified: llvm/trunk/lib/CodeGen/VirtRegRewriter.cpp
URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/lib/CodeGen/VirtRegRewriter.cpp?rev=83871&r1=83870&r2=83871&view=diff
==============================================================================
--- llvm/trunk/lib/CodeGen/VirtRegRewriter.cpp (original)
+++ llvm/trunk/lib/CodeGen/VirtRegRewriter.cpp Mon Oct 12 13:49:00 2009
@@ -1478,6 +1478,29 @@
++NumStores;
}
+ /// isSafeToDelete - Return true if this instruction doesn't produce any side
+ /// effect and all of its defs are dead.
+ static bool isSafeToDelete(MachineInstr &MI) {
+ const TargetInstrDesc &TID = MI.getDesc();
+ if (TID.mayLoad() || TID.mayStore() || TID.isCall() || TID.isTerminator() ||
+ TID.isCall() || TID.isBarrier() || TID.isReturn() ||
+ TID.hasUnmodeledSideEffects())
+ return false;
+ for (unsigned i = 0, e = MI.getNumOperands(); i != e; ++i) {
+ MachineOperand &MO = MI.getOperand(i);
+ if (!MO.isReg() || !MO.getReg())
+ continue;
+ if (MO.isDef() && !MO.isDead())
+ return false;
+ if (MO.isUse() && MO.isKill())
+ // FIXME: We can't remove kill markers or else the scavenger will assert.
+ // An alternative is to add a ADD pseudo instruction to replace kill
+ // markers.
+ return false;
+ }
+ return true;
+ }
+
/// TransferDeadness - A identity copy definition is dead and it's being
/// removed. Find the last def or use and mark it as dead / kill.
void TransferDeadness(MachineBasicBlock *MBB, unsigned CurDist,
@@ -1519,7 +1542,7 @@
if (LastUD->isDef()) {
// If the instruction has no side effect, delete it and propagate
// backward further. Otherwise, mark is dead and we are done.
- if (!TII->isDeadInstruction(LastUDMI)) {
+ if (!isSafeToDelete(*LastUDMI)) {
LastUD->setIsDead();
break;
}
@@ -2340,7 +2363,7 @@
}
ProcessNextInst:
// Delete dead instructions without side effects.
- if (!Erased && !BackTracked && TII->isDeadInstruction(&MI)) {
+ if (!Erased && !BackTracked && isSafeToDelete(MI)) {
InvalidateKills(MI, TRI, RegKills, KillOps);
VRM.RemoveMachineInstrFromMaps(&MI);
MBB.erase(&MI);
Modified: llvm/trunk/lib/Target/PowerPC/PPCInstrInfo.h
URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/lib/Target/PowerPC/PPCInstrInfo.h?rev=83871&r1=83870&r2=83871&view=diff
==============================================================================
--- llvm/trunk/lib/Target/PowerPC/PPCInstrInfo.h (original)
+++ llvm/trunk/lib/Target/PowerPC/PPCInstrInfo.h Mon Oct 12 13:49:00 2009
@@ -146,13 +146,6 @@
virtual bool BlockHasNoFallThrough(const MachineBasicBlock &MBB) const;
virtual
bool ReverseBranchCondition(SmallVectorImpl &Cond) const;
-
- virtual bool isDeadInstruction(const MachineInstr *MI) const {
- // FIXME: Without this, ppc llvm-gcc doesn't bootstrap. That means some
- // instruction definitions are not modeling side effects correctly.
- // This is a workaround until we know the exact cause.
- return false;
- }
/// GetInstSize - Return the number of bytes of code the specified
/// instruction may be. This returns the maximum number of bytes.
From bob.wilson at apple.com Mon Oct 12 13:52:13 2009
From: bob.wilson at apple.com (Bob Wilson)
Date: Mon, 12 Oct 2009 18:52:13 -0000
Subject: [llvm-commits] [llvm] r83872 -
/llvm/trunk/lib/Target/ARM/ARMConstantIslandPass.cpp
Message-ID: <200910121852.n9CIqDY3019356@zion.cs.uiuc.edu>
Author: bwilson
Date: Mon Oct 12 13:52:13 2009
New Revision: 83872
URL: http://llvm.org/viewvc/llvm-project?rev=83872&view=rev
Log:
Add a typedef for an iterator.
Modified:
llvm/trunk/lib/Target/ARM/ARMConstantIslandPass.cpp
Modified: llvm/trunk/lib/Target/ARM/ARMConstantIslandPass.cpp
URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/lib/Target/ARM/ARMConstantIslandPass.cpp?rev=83872&r1=83871&r2=83872&view=diff
==============================================================================
--- llvm/trunk/lib/Target/ARM/ARMConstantIslandPass.cpp (original)
+++ llvm/trunk/lib/Target/ARM/ARMConstantIslandPass.cpp Mon Oct 12 13:52:13 2009
@@ -70,6 +70,8 @@
/// to a return, unreachable, or unconditional branch).
std::vector WaterList;
+ typedef std::vector::iterator water_iterator;
+
/// CPUser - One user of a constant pool, keeping the machine instruction
/// pointer, the constant pool being referenced, and the max displacement
/// allowed from the instruction to the CP.
@@ -164,7 +166,7 @@
bool LookForWater(CPUser&U, unsigned UserOffset,
MachineBasicBlock** NewMBB);
MachineBasicBlock* AcceptWater(MachineBasicBlock *WaterBB,
- std::vector::iterator IP);
+ water_iterator IP);
void CreateNewWater(unsigned CPUserIndex, unsigned UserOffset,
MachineBasicBlock** NewMBB);
bool HandleConstantPoolUser(MachineFunction &MF, unsigned CPUserIndex);
@@ -608,7 +610,7 @@
// Next, update WaterList. Specifically, we need to add NewMBB as having
// available water after it.
- std::vector::iterator IP =
+ water_iterator IP =
std::lower_bound(WaterList.begin(), WaterList.end(), NewBB,
CompareMBBNumbers);
WaterList.insert(IP, NewBB);
@@ -670,7 +672,7 @@
// available water after it (but not if it's already there, which happens
// when splitting before a conditional branch that is followed by an
// unconditional branch - in that case we want to insert NewBB).
- std::vector::iterator IP =
+ water_iterator IP =
std::lower_bound(WaterList.begin(), WaterList.end(), OrigBB,
CompareMBBNumbers);
MachineBasicBlock* WaterBB = *IP;
@@ -932,7 +934,7 @@
/// AcceptWater - Small amount of common code factored out of the following.
MachineBasicBlock* ARMConstantIslands::AcceptWater(MachineBasicBlock *WaterBB,
- std::vector::iterator IP) {
+ water_iterator IP) {
DEBUG(errs() << "found water in range\n");
// Remove the original WaterList entry; we want subsequent
// insertions in this vicinity to go after the one we're
@@ -952,10 +954,10 @@
/// group, prefer the water that's farthest away.
bool ARMConstantIslands::LookForWater(CPUser &U, unsigned UserOffset,
MachineBasicBlock** NewMBB) {
- std::vector::iterator IPThatWouldPad;
+ water_iterator IPThatWouldPad;
MachineBasicBlock* WaterBBThatWouldPad = NULL;
if (!WaterList.empty()) {
- for (std::vector::iterator IP = prior(WaterList.end()),
+ for (water_iterator IP = prior(WaterList.end()),
B = WaterList.begin();; --IP) {
MachineBasicBlock* WaterBB = *IP;
if (WaterIsInRange(UserOffset, WaterBB, U)) {
From bob.wilson at apple.com Mon Oct 12 14:01:13 2009
From: bob.wilson at apple.com (Bob Wilson)
Date: Mon, 12 Oct 2009 19:01:13 -0000
Subject: [llvm-commits] [llvm] r83873 -
/llvm/trunk/lib/Target/ARM/ARMConstantIslandPass.cpp
Message-ID: <200910121901.n9CJ1Dib019874@zion.cs.uiuc.edu>
Author: bwilson
Date: Mon Oct 12 14:01:12 2009
New Revision: 83873
URL: http://llvm.org/viewvc/llvm-project?rev=83873&view=rev
Log:
Change to return a value by reference.
Modified:
llvm/trunk/lib/Target/ARM/ARMConstantIslandPass.cpp
Modified: llvm/trunk/lib/Target/ARM/ARMConstantIslandPass.cpp
URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/lib/Target/ARM/ARMConstantIslandPass.cpp?rev=83873&r1=83872&r2=83873&view=diff
==============================================================================
--- llvm/trunk/lib/Target/ARM/ARMConstantIslandPass.cpp (original)
+++ llvm/trunk/lib/Target/ARM/ARMConstantIslandPass.cpp Mon Oct 12 14:01:12 2009
@@ -164,7 +164,7 @@
bool DecrementOldEntry(unsigned CPI, MachineInstr* CPEMI);
int LookForExistingCPEntry(CPUser& U, unsigned UserOffset);
bool LookForWater(CPUser&U, unsigned UserOffset,
- MachineBasicBlock** NewMBB);
+ MachineBasicBlock *&NewMBB);
MachineBasicBlock* AcceptWater(MachineBasicBlock *WaterBB,
water_iterator IP);
void CreateNewWater(unsigned CPUserIndex, unsigned UserOffset,
@@ -947,13 +947,13 @@
/// LookForWater - look for an existing entry in the WaterList in which
/// we can place the CPE referenced from U so it's within range of U's MI.
-/// Returns true if found, false if not. If it returns true, *NewMBB
+/// Returns true if found, false if not. If it returns true, NewMBB
/// is set to the WaterList entry.
/// For ARM, we prefer the water that's farthest away. For Thumb, prefer
/// water that will not introduce padding to water that will; within each
/// group, prefer the water that's farthest away.
bool ARMConstantIslands::LookForWater(CPUser &U, unsigned UserOffset,
- MachineBasicBlock** NewMBB) {
+ MachineBasicBlock *&NewMBB) {
water_iterator IPThatWouldPad;
MachineBasicBlock* WaterBBThatWouldPad = NULL;
if (!WaterList.empty()) {
@@ -971,7 +971,7 @@
IPThatWouldPad = IP;
}
} else {
- *NewMBB = AcceptWater(WaterBB, IP);
+ NewMBB = AcceptWater(WaterBB, IP);
return true;
}
}
@@ -980,7 +980,7 @@
}
}
if (isThumb && WaterBBThatWouldPad) {
- *NewMBB = AcceptWater(WaterBBThatWouldPad, IPThatWouldPad);
+ NewMBB = AcceptWater(WaterBBThatWouldPad, IPThatWouldPad);
return true;
}
return false;
@@ -1114,7 +1114,7 @@
// away that will work. Forward references only for now (although later
// we might find some that are backwards).
- if (!LookForWater(U, UserOffset, &NewMBB)) {
+ if (!LookForWater(U, UserOffset, NewMBB)) {
// No water found.
DEBUG(errs() << "No water found\n");
CreateNewWater(CPUserIndex, UserOffset, &NewMBB);
From bob.wilson at apple.com Mon Oct 12 14:04:03 2009
From: bob.wilson at apple.com (Bob Wilson)
Date: Mon, 12 Oct 2009 19:04:03 -0000
Subject: [llvm-commits] [llvm] r83874 -
/llvm/trunk/lib/Target/ARM/ARMConstantIslandPass.cpp
Message-ID: <200910121904.n9CJ43OL020135@zion.cs.uiuc.edu>
Author: bwilson
Date: Mon Oct 12 14:04:03 2009
New Revision: 83874
URL: http://llvm.org/viewvc/llvm-project?rev=83874&view=rev
Log:
Use early exit to reduce indentation.
Modified:
llvm/trunk/lib/Target/ARM/ARMConstantIslandPass.cpp
Modified: llvm/trunk/lib/Target/ARM/ARMConstantIslandPass.cpp
URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/lib/Target/ARM/ARMConstantIslandPass.cpp?rev=83874&r1=83873&r2=83874&view=diff
==============================================================================
--- llvm/trunk/lib/Target/ARM/ARMConstantIslandPass.cpp (original)
+++ llvm/trunk/lib/Target/ARM/ARMConstantIslandPass.cpp Mon Oct 12 14:04:03 2009
@@ -956,28 +956,29 @@
MachineBasicBlock *&NewMBB) {
water_iterator IPThatWouldPad;
MachineBasicBlock* WaterBBThatWouldPad = NULL;
- if (!WaterList.empty()) {
- for (water_iterator IP = prior(WaterList.end()),
- B = WaterList.begin();; --IP) {
- MachineBasicBlock* WaterBB = *IP;
- if (WaterIsInRange(UserOffset, WaterBB, U)) {
- unsigned WBBId = WaterBB->getNumber();
- if (isThumb &&
- (BBOffsets[WBBId] + BBSizes[WBBId])%4 != 0) {
- // This is valid Water, but would introduce padding. Remember
- // it in case we don't find any Water that doesn't do this.
- if (!WaterBBThatWouldPad) {
- WaterBBThatWouldPad = WaterBB;
- IPThatWouldPad = IP;
- }
- } else {
- NewMBB = AcceptWater(WaterBB, IP);
- return true;
+ if (WaterList.empty())
+ return false;
+
+ for (water_iterator IP = prior(WaterList.end()),
+ B = WaterList.begin();; --IP) {
+ MachineBasicBlock* WaterBB = *IP;
+ if (WaterIsInRange(UserOffset, WaterBB, U)) {
+ unsigned WBBId = WaterBB->getNumber();
+ if (isThumb &&
+ (BBOffsets[WBBId] + BBSizes[WBBId])%4 != 0) {
+ // This is valid Water, but would introduce padding. Remember
+ // it in case we don't find any Water that doesn't do this.
+ if (!WaterBBThatWouldPad) {
+ WaterBBThatWouldPad = WaterBB;
+ IPThatWouldPad = IP;
}
+ } else {
+ NewMBB = AcceptWater(WaterBB, IP);
+ return true;
}
- if (IP == B)
- break;
}
+ if (IP == B)
+ break;
}
if (isThumb && WaterBBThatWouldPad) {
NewMBB = AcceptWater(WaterBBThatWouldPad, IPThatWouldPad);
From baldrick at free.fr Mon Oct 12 14:31:15 2009
From: baldrick at free.fr (Duncan Sands)
Date: Mon, 12 Oct 2009 19:31:15 -0000
Subject: [llvm-commits] [llvm-gcc-4.2] r83875 -
/llvm-gcc-4.2/trunk/gcc/config/i386/llvm-i386.cpp
Message-ID: <200910121931.n9CJVFbP021229@zion.cs.uiuc.edu>
Author: baldrick
Date: Mon Oct 12 14:31:15 2009
New Revision: 83875
URL: http://llvm.org/viewvc/llvm-project?rev=83875&view=rev
Log:
Port of dragonegg commit 83637: Remove useless value names ("tmp") -
these are not helpful, and they fatten the bitcode.
Modified:
llvm-gcc-4.2/trunk/gcc/config/i386/llvm-i386.cpp
Modified: llvm-gcc-4.2/trunk/gcc/config/i386/llvm-i386.cpp
URL: http://llvm.org/viewvc/llvm-project/llvm-gcc-4.2/trunk/gcc/config/i386/llvm-i386.cpp?rev=83875&r1=83874&r2=83875&view=diff
==============================================================================
--- llvm-gcc-4.2/trunk/gcc/config/i386/llvm-i386.cpp (original)
+++ llvm-gcc-4.2/trunk/gcc/config/i386/llvm-i386.cpp Mon Oct 12 14:31:15 2009
@@ -62,7 +62,7 @@
case IX86_BUILTIN_PADDW128:
case IX86_BUILTIN_PADDD128:
case IX86_BUILTIN_PADDQ128:
- Result = Builder.CreateAdd(Ops[0], Ops[1], "tmp");
+ Result = Builder.CreateAdd(Ops[0], Ops[1]);
return true;
case IX86_BUILTIN_SUBPS:
case IX86_BUILTIN_SUBPD:
@@ -74,34 +74,34 @@
case IX86_BUILTIN_PSUBW128:
case IX86_BUILTIN_PSUBD128:
case IX86_BUILTIN_PSUBQ128:
- Result = Builder.CreateSub(Ops[0], Ops[1], "tmp");
+ Result = Builder.CreateSub(Ops[0], Ops[1]);
return true;
case IX86_BUILTIN_MULPS:
case IX86_BUILTIN_MULPD:
case IX86_BUILTIN_PMULLW:
case IX86_BUILTIN_PMULLW128:
- Result = Builder.CreateMul(Ops[0], Ops[1], "tmp");
+ Result = Builder.CreateMul(Ops[0], Ops[1]);
return true;
case IX86_BUILTIN_DIVPS:
case IX86_BUILTIN_DIVPD:
- Result = Builder.CreateFDiv(Ops[0], Ops[1], "tmp");
+ Result = Builder.CreateFDiv(Ops[0], Ops[1]);
return true;
case IX86_BUILTIN_PAND:
case IX86_BUILTIN_PAND128:
- Result = Builder.CreateAnd(Ops[0], Ops[1], "tmp");
+ Result = Builder.CreateAnd(Ops[0], Ops[1]);
return true;
case IX86_BUILTIN_PANDN:
case IX86_BUILTIN_PANDN128:
- Ops[0] = Builder.CreateNot(Ops[0], "tmp");
- Result = Builder.CreateAnd(Ops[0], Ops[1], "tmp");
+ Ops[0] = Builder.CreateNot(Ops[0]);
+ Result = Builder.CreateAnd(Ops[0], Ops[1]);
return true;
case IX86_BUILTIN_POR:
case IX86_BUILTIN_POR128:
- Result = Builder.CreateOr(Ops[0], Ops[1], "tmp");
+ Result = Builder.CreateOr(Ops[0], Ops[1]);
return true;
case IX86_BUILTIN_PXOR:
case IX86_BUILTIN_PXOR128:
- Result = Builder.CreateXor(Ops[0], Ops[1], "tmp");
+ Result = Builder.CreateXor(Ops[0], Ops[1]);
return true;
case IX86_BUILTIN_ANDPS:
case IX86_BUILTIN_ORPS:
@@ -120,27 +120,27 @@
VectorType::get(Type::getInt64Ty(Context), 2),
"tmp");
- Ops[1] = Builder.CreateBitCast(Ops[1], Ops[0]->getType(), "tmp");
+ Ops[1] = Builder.CreateBitCast(Ops[1], Ops[0]->getType());
switch (FnCode) {
case IX86_BUILTIN_ANDPS:
case IX86_BUILTIN_ANDPD:
- Result = Builder.CreateAnd(Ops[0], Ops[1], "tmp");
+ Result = Builder.CreateAnd(Ops[0], Ops[1]);
break;
case IX86_BUILTIN_ORPS:
case IX86_BUILTIN_ORPD:
- Result = Builder.CreateOr (Ops[0], Ops[1], "tmp");
+ Result = Builder.CreateOr (Ops[0], Ops[1]);
break;
case IX86_BUILTIN_XORPS:
case IX86_BUILTIN_XORPD:
- Result = Builder.CreateXor(Ops[0], Ops[1], "tmp");
+ Result = Builder.CreateXor(Ops[0], Ops[1]);
break;
case IX86_BUILTIN_ANDNPS:
case IX86_BUILTIN_ANDNPD:
- Ops[0] = Builder.CreateNot(Ops[0], "tmp");
- Result = Builder.CreateAnd(Ops[0], Ops[1], "tmp");
+ Ops[0] = Builder.CreateNot(Ops[0]);
+ Result = Builder.CreateAnd(Ops[0], Ops[1]);
break;
}
- Result = Builder.CreateBitCast(Result, ResultType, "tmp");
+ Result = Builder.CreateBitCast(Result, ResultType);
return true;
case IX86_BUILTIN_SHUFPS:
if (ConstantInt *Elt = dyn_cast(Ops[2])) {
@@ -280,20 +280,20 @@
}
case IX86_BUILTIN_LOADQ: {
PointerType *i64Ptr = PointerType::getUnqual(Type::getInt64Ty(Context));
- Ops[0] = Builder.CreateBitCast(Ops[0], i64Ptr, "tmp");
- Ops[0] = Builder.CreateLoad(Ops[0], "tmp");
+ Ops[0] = Builder.CreateBitCast(Ops[0], i64Ptr);
+ Ops[0] = Builder.CreateLoad(Ops[0]);
Value *Zero = ConstantInt::get(Type::getInt64Ty(Context), 0);
Result = BuildVector(Zero, Zero, NULL);
Value *Idx = ConstantInt::get(Type::getInt32Ty(Context), 0);
- Result = Builder.CreateInsertElement(Result, Ops[0], Idx, "tmp");
- Result = Builder.CreateBitCast(Result, ResultType, "tmp");
+ Result = Builder.CreateInsertElement(Result, Ops[0], Idx);
+ Result = Builder.CreateBitCast(Result, ResultType);
return true;
}
case IX86_BUILTIN_LOADUPS: {
VectorType *v4f32 = VectorType::get(Type::getFloatTy(Context), 4);
PointerType *v4f32Ptr = PointerType::getUnqual(v4f32);
- Value *BC = Builder.CreateBitCast(Ops[0], v4f32Ptr, "tmp");
- LoadInst *LI = Builder.CreateLoad(BC, "tmp");
+ Value *BC = Builder.CreateBitCast(Ops[0], v4f32Ptr);
+ LoadInst *LI = Builder.CreateLoad(BC);
LI->setAlignment(1);
Result = LI;
return true;
@@ -301,8 +301,8 @@
case IX86_BUILTIN_LOADUPD: {
VectorType *v2f64 = VectorType::get(Type::getDoubleTy(Context), 2);
PointerType *v2f64Ptr = PointerType::getUnqual(v2f64);
- Value *BC = Builder.CreateBitCast(Ops[0], v2f64Ptr, "tmp");
- LoadInst *LI = Builder.CreateLoad(BC, "tmp");
+ Value *BC = Builder.CreateBitCast(Ops[0], v2f64Ptr);
+ LoadInst *LI = Builder.CreateLoad(BC);
LI->setAlignment(1);
Result = LI;
return true;
@@ -310,8 +310,8 @@
case IX86_BUILTIN_LOADDQU: {
VectorType *v16i8 = VectorType::get(Type::getInt8Ty(Context), 16);
PointerType *v16i8Ptr = PointerType::getUnqual(v16i8);
- Value *BC = Builder.CreateBitCast(Ops[0], v16i8Ptr, "tmp");
- LoadInst *LI = Builder.CreateLoad(BC, "tmp");
+ Value *BC = Builder.CreateBitCast(Ops[0], v16i8Ptr);
+ LoadInst *LI = Builder.CreateLoad(BC);
LI->setAlignment(1);
Result = LI;
return true;
@@ -319,7 +319,7 @@
case IX86_BUILTIN_STOREUPS: {
VectorType *v4f32 = VectorType::get(Type::getFloatTy(Context), 4);
PointerType *v4f32Ptr = PointerType::getUnqual(v4f32);
- Value *BC = Builder.CreateBitCast(Ops[0], v4f32Ptr, "tmp");
+ Value *BC = Builder.CreateBitCast(Ops[0], v4f32Ptr);
StoreInst *SI = Builder.CreateStore(Ops[1], BC);
SI->setAlignment(1);
Result = SI;
@@ -328,7 +328,7 @@
case IX86_BUILTIN_STOREUPD: {
VectorType *v2f64 = VectorType::get(Type::getDoubleTy(Context), 2);
PointerType *v2f64Ptr = PointerType::getUnqual(v2f64);
- Value *BC = Builder.CreateBitCast(Ops[0], v2f64Ptr, "tmp");
+ Value *BC = Builder.CreateBitCast(Ops[0], v2f64Ptr);
StoreInst *SI = Builder.CreateStore(Ops[1], BC);
SI->setAlignment(1);
Result = SI;
@@ -337,7 +337,7 @@
case IX86_BUILTIN_STOREDQU: {
VectorType *v16i8 = VectorType::get(Type::getInt8Ty(Context), 16);
PointerType *v16i8Ptr = PointerType::getUnqual(v16i8);
- Value *BC = Builder.CreateBitCast(Ops[0], v16i8Ptr, "tmp");
+ Value *BC = Builder.CreateBitCast(Ops[0], v16i8Ptr);
StoreInst *SI = Builder.CreateStore(Ops[1], BC);
SI->setAlignment(1);
Result = SI;
@@ -345,57 +345,57 @@
}
case IX86_BUILTIN_LOADHPS: {
PointerType *f64Ptr = PointerType::getUnqual(Type::getDoubleTy(Context));
- Ops[1] = Builder.CreateBitCast(Ops[1], f64Ptr, "tmp");
- Value *Load = Builder.CreateLoad(Ops[1], "tmp");
+ Ops[1] = Builder.CreateBitCast(Ops[1], f64Ptr);
+ Value *Load = Builder.CreateLoad(Ops[1]);
Ops[1] = BuildVector(Load, UndefValue::get(Type::getDoubleTy(Context)), NULL);
- Ops[1] = Builder.CreateBitCast(Ops[1], ResultType, "tmp");
+ Ops[1] = Builder.CreateBitCast(Ops[1], ResultType);
Result = BuildVectorShuffle(Ops[0], Ops[1], 0, 1, 4, 5);
- Result = Builder.CreateBitCast(Result, ResultType, "tmp");
+ Result = Builder.CreateBitCast(Result, ResultType);
return true;
}
case IX86_BUILTIN_LOADLPS: {
PointerType *f64Ptr = PointerType::getUnqual(Type::getDoubleTy(Context));
- Ops[1] = Builder.CreateBitCast(Ops[1], f64Ptr, "tmp");
- Value *Load = Builder.CreateLoad(Ops[1], "tmp");
+ Ops[1] = Builder.CreateBitCast(Ops[1], f64Ptr);
+ Value *Load = Builder.CreateLoad(Ops[1]);
Ops[1] = BuildVector(Load, UndefValue::get(Type::getDoubleTy(Context)), NULL);
- Ops[1] = Builder.CreateBitCast(Ops[1], ResultType, "tmp");
+ Ops[1] = Builder.CreateBitCast(Ops[1], ResultType);
Result = BuildVectorShuffle(Ops[0], Ops[1], 4, 5, 2, 3);
- Result = Builder.CreateBitCast(Result, ResultType, "tmp");
+ Result = Builder.CreateBitCast(Result, ResultType);
return true;
}
case IX86_BUILTIN_LOADHPD: {
- Value *Load = Builder.CreateLoad(Ops[1], "tmp");
+ Value *Load = Builder.CreateLoad(Ops[1]);
Ops[1] = BuildVector(Load, UndefValue::get(Type::getDoubleTy(Context)), NULL);
- Ops[1] = Builder.CreateBitCast(Ops[1], ResultType, "tmp");
+ Ops[1] = Builder.CreateBitCast(Ops[1], ResultType);
Result = BuildVectorShuffle(Ops[0], Ops[1], 0, 2);
- Result = Builder.CreateBitCast(Result, ResultType, "tmp");
+ Result = Builder.CreateBitCast(Result, ResultType);
return true;
}
case IX86_BUILTIN_LOADLPD: {
- Value *Load = Builder.CreateLoad(Ops[1], "tmp");
+ Value *Load = Builder.CreateLoad(Ops[1]);
Ops[1] = BuildVector(Load, UndefValue::get(Type::getDoubleTy(Context)), NULL);
- Ops[1] = Builder.CreateBitCast(Ops[1], ResultType, "tmp");
+ Ops[1] = Builder.CreateBitCast(Ops[1], ResultType);
Result = BuildVectorShuffle(Ops[0], Ops[1], 2, 1);
- Result = Builder.CreateBitCast(Result, ResultType, "tmp");
+ Result = Builder.CreateBitCast(Result, ResultType);
return true;
}
case IX86_BUILTIN_STOREHPS: {
VectorType *v2f64 = VectorType::get(Type::getDoubleTy(Context), 2);
PointerType *f64Ptr = PointerType::getUnqual(Type::getDoubleTy(Context));
- Ops[0] = Builder.CreateBitCast(Ops[0], f64Ptr, "tmp");
+ Ops[0] = Builder.CreateBitCast(Ops[0], f64Ptr);
Value *Idx = ConstantInt::get(Type::getInt32Ty(Context), 1);
- Ops[1] = Builder.CreateBitCast(Ops[1], v2f64, "tmp");
- Ops[1] = Builder.CreateExtractElement(Ops[1], Idx, "tmp");
+ Ops[1] = Builder.CreateBitCast(Ops[1], v2f64);
+ Ops[1] = Builder.CreateExtractElement(Ops[1], Idx);
Result = Builder.CreateStore(Ops[1], Ops[0]);
return true;
}
case IX86_BUILTIN_STORELPS: {
VectorType *v2f64 = VectorType::get(Type::getDoubleTy(Context), 2);
PointerType *f64Ptr = PointerType::getUnqual(Type::getDoubleTy(Context));
- Ops[0] = Builder.CreateBitCast(Ops[0], f64Ptr, "tmp");
+ Ops[0] = Builder.CreateBitCast(Ops[0], f64Ptr);
Value *Idx = ConstantInt::get(Type::getInt32Ty(Context), 0);
- Ops[1] = Builder.CreateBitCast(Ops[1], v2f64, "tmp");
- Ops[1] = Builder.CreateExtractElement(Ops[1], Idx, "tmp");
+ Ops[1] = Builder.CreateBitCast(Ops[1], v2f64);
+ Ops[1] = Builder.CreateExtractElement(Ops[1], Idx);
Result = Builder.CreateStore(Ops[1], Ops[0]);
return true;
}
@@ -411,13 +411,13 @@
case IX86_BUILTIN_VEC_INIT_V4HI:
// Sometimes G++ promotes arguments to int.
for (unsigned i = 0; i != 4; ++i)
- Ops[i] = Builder.CreateIntCast(Ops[i], Type::getInt16Ty(Context), false, "tmp");
+ Ops[i] = Builder.CreateIntCast(Ops[i], Type::getInt16Ty(Context), false);
Result = BuildVector(Ops[0], Ops[1], Ops[2], Ops[3], NULL);
return true;
case IX86_BUILTIN_VEC_INIT_V8QI:
// Sometimes G++ promotes arguments to int.
for (unsigned i = 0; i != 8; ++i)
- Ops[i] = Builder.CreateIntCast(Ops[i], Type::getInt8Ty(Context), false, "tmp");
+ Ops[i] = Builder.CreateIntCast(Ops[i], Type::getInt8Ty(Context), false);
Result = BuildVector(Ops[0], Ops[1], Ops[2], Ops[3],
Ops[4], Ops[5], Ops[6], Ops[7], NULL);
return true;
@@ -429,24 +429,24 @@
case IX86_BUILTIN_VEC_EXT_V4SF:
case IX86_BUILTIN_VEC_EXT_V8HI:
case IX86_BUILTIN_VEC_EXT_V16QI:
- Result = Builder.CreateExtractElement(Ops[0], Ops[1], "tmp");
+ Result = Builder.CreateExtractElement(Ops[0], Ops[1]);
return true;
case IX86_BUILTIN_VEC_SET_V16QI:
// Sometimes G++ promotes arguments to int.
- Ops[1] = Builder.CreateIntCast(Ops[1], Type::getInt8Ty(Context), false, "tmp");
- Result = Builder.CreateInsertElement(Ops[0], Ops[1], Ops[2], "tmp");
+ Ops[1] = Builder.CreateIntCast(Ops[1], Type::getInt8Ty(Context), false);
+ Result = Builder.CreateInsertElement(Ops[0], Ops[1], Ops[2]);
return true;
case IX86_BUILTIN_VEC_SET_V4HI:
case IX86_BUILTIN_VEC_SET_V8HI:
// GCC sometimes doesn't produce the right element type.
- Ops[1] = Builder.CreateIntCast(Ops[1], Type::getInt16Ty(Context), false, "tmp");
- Result = Builder.CreateInsertElement(Ops[0], Ops[1], Ops[2], "tmp");
+ Ops[1] = Builder.CreateIntCast(Ops[1], Type::getInt16Ty(Context), false);
+ Result = Builder.CreateInsertElement(Ops[0], Ops[1], Ops[2]);
return true;
case IX86_BUILTIN_VEC_SET_V4SI:
- Result = Builder.CreateInsertElement(Ops[0], Ops[1], Ops[2], "tmp");
+ Result = Builder.CreateInsertElement(Ops[0], Ops[1], Ops[2]);
return true;
case IX86_BUILTIN_VEC_SET_V2DI:
- Result = Builder.CreateInsertElement(Ops[0], Ops[1], Ops[2], "tmp");
+ Result = Builder.CreateInsertElement(Ops[0], Ops[1], Ops[2]);
return true;
case IX86_BUILTIN_CMPEQPS:
case IX86_BUILTIN_CMPLTPS:
@@ -484,8 +484,8 @@
Value *Arg1 = Ops[1];
if (flip) std::swap(Arg0, Arg1);
Value *CallOps[3] = { Arg0, Arg1, Pred };
- Result = Builder.CreateCall(cmpps, CallOps, CallOps+3, "tmp");
- Result = Builder.CreateBitCast(Result, ResultType, "tmp");
+ Result = Builder.CreateCall(cmpps, CallOps, CallOps+3);
+ Result = Builder.CreateBitCast(Result, ResultType);
return true;
}
case IX86_BUILTIN_CMPEQSS:
@@ -514,8 +514,8 @@
}
Value *Pred = ConstantInt::get(Type::getInt8Ty(Context), PredCode);
Value *CallOps[3] = { Ops[0], Ops[1], Pred };
- Result = Builder.CreateCall(cmpss, CallOps, CallOps+3, "tmp");
- Result = Builder.CreateBitCast(Result, ResultType, "tmp");
+ Result = Builder.CreateCall(cmpss, CallOps, CallOps+3);
+ Result = Builder.CreateBitCast(Result, ResultType);
return true;
}
case IX86_BUILTIN_CMPEQPD:
@@ -555,8 +555,8 @@
if (flip) std::swap(Arg0, Arg1);
Value *CallOps[3] = { Arg0, Arg1, Pred };
- Result = Builder.CreateCall(cmppd, CallOps, CallOps+3, "tmp");
- Result = Builder.CreateBitCast(Result, ResultType, "tmp");
+ Result = Builder.CreateCall(cmppd, CallOps, CallOps+3);
+ Result = Builder.CreateBitCast(Result, ResultType);
return true;
}
case IX86_BUILTIN_CMPEQSD:
@@ -583,8 +583,8 @@
}
Value *Pred = ConstantInt::get(Type::getInt8Ty(Context), PredCode);
Value *CallOps[3] = { Ops[0], Ops[1], Pred };
- Result = Builder.CreateCall(cmpsd, CallOps, CallOps+3, "tmp");
- Result = Builder.CreateBitCast(Result, ResultType, "tmp");
+ Result = Builder.CreateCall(cmpsd, CallOps, CallOps+3);
+ Result = Builder.CreateBitCast(Result, ResultType);
return true;
}
case IX86_BUILTIN_LDMXCSR: {
@@ -593,7 +593,7 @@
Value *Ptr = CreateTemporary(Type::getInt32Ty(Context));
Builder.CreateStore(Ops[0], Ptr);
Ptr = Builder.CreateBitCast(Ptr,
- PointerType::getUnqual(Type::getInt8Ty(Context)), "tmp");
+ PointerType::getUnqual(Type::getInt8Ty(Context)));
Result = Builder.CreateCall(ldmxcsr, Ptr);
return true;
}
@@ -602,10 +602,10 @@
Intrinsic::getDeclaration(TheModule, Intrinsic::x86_sse_stmxcsr);
Value *Ptr = CreateTemporary(Type::getInt32Ty(Context));
Value *BPtr = Builder.CreateBitCast(Ptr,
- PointerType::getUnqual(Type::getInt8Ty(Context)), "tmp");
+ PointerType::getUnqual(Type::getInt8Ty(Context)));
Builder.CreateCall(stmxcsr, BPtr);
- Result = Builder.CreateLoad(Ptr, "tmp");
+ Result = Builder.CreateLoad(Ptr);
return true;
}
}
From baldrick at free.fr Mon Oct 12 14:35:13 2009
From: baldrick at free.fr (Duncan Sands)
Date: Mon, 12 Oct 2009 19:35:13 -0000
Subject: [llvm-commits] [llvm-gcc-4.2] r83876 - in /llvm-gcc-4.2/trunk/gcc:
config/i386/llvm-i386.cpp llvm-abi.h llvm-backend.cpp llvm-convert.cpp
llvm-types.cpp
Message-ID: <200910121935.n9CJZE6h021494@zion.cs.uiuc.edu>
Author: baldrick
Date: Mon Oct 12 14:35:13 2009
New Revision: 83876
URL: http://llvm.org/viewvc/llvm-project?rev=83876&view=rev
Log:
Port of dragonegg commit 83402: Simplify the creation of pointer types.
Modified:
llvm-gcc-4.2/trunk/gcc/config/i386/llvm-i386.cpp
llvm-gcc-4.2/trunk/gcc/llvm-abi.h
llvm-gcc-4.2/trunk/gcc/llvm-backend.cpp
llvm-gcc-4.2/trunk/gcc/llvm-convert.cpp
llvm-gcc-4.2/trunk/gcc/llvm-types.cpp
Modified: llvm-gcc-4.2/trunk/gcc/config/i386/llvm-i386.cpp
URL: http://llvm.org/viewvc/llvm-project/llvm-gcc-4.2/trunk/gcc/config/i386/llvm-i386.cpp?rev=83876&r1=83875&r2=83876&view=diff
==============================================================================
--- llvm-gcc-4.2/trunk/gcc/config/i386/llvm-i386.cpp (original)
+++ llvm-gcc-4.2/trunk/gcc/config/i386/llvm-i386.cpp Mon Oct 12 14:35:13 2009
@@ -279,7 +279,7 @@
return true;
}
case IX86_BUILTIN_LOADQ: {
- PointerType *i64Ptr = PointerType::getUnqual(Type::getInt64Ty(Context));
+ const PointerType *i64Ptr = Type::getInt64PtrTy(Context);
Ops[0] = Builder.CreateBitCast(Ops[0], i64Ptr);
Ops[0] = Builder.CreateLoad(Ops[0]);
Value *Zero = ConstantInt::get(Type::getInt64Ty(Context), 0);
@@ -291,7 +291,7 @@
}
case IX86_BUILTIN_LOADUPS: {
VectorType *v4f32 = VectorType::get(Type::getFloatTy(Context), 4);
- PointerType *v4f32Ptr = PointerType::getUnqual(v4f32);
+ const PointerType *v4f32Ptr = v4f32->getPointerTo();
Value *BC = Builder.CreateBitCast(Ops[0], v4f32Ptr);
LoadInst *LI = Builder.CreateLoad(BC);
LI->setAlignment(1);
@@ -300,7 +300,7 @@
}
case IX86_BUILTIN_LOADUPD: {
VectorType *v2f64 = VectorType::get(Type::getDoubleTy(Context), 2);
- PointerType *v2f64Ptr = PointerType::getUnqual(v2f64);
+ const PointerType *v2f64Ptr = v2f64->getPointerTo();
Value *BC = Builder.CreateBitCast(Ops[0], v2f64Ptr);
LoadInst *LI = Builder.CreateLoad(BC);
LI->setAlignment(1);
@@ -309,7 +309,7 @@
}
case IX86_BUILTIN_LOADDQU: {
VectorType *v16i8 = VectorType::get(Type::getInt8Ty(Context), 16);
- PointerType *v16i8Ptr = PointerType::getUnqual(v16i8);
+ const PointerType *v16i8Ptr = v16i8->getPointerTo();
Value *BC = Builder.CreateBitCast(Ops[0], v16i8Ptr);
LoadInst *LI = Builder.CreateLoad(BC);
LI->setAlignment(1);
@@ -318,7 +318,7 @@
}
case IX86_BUILTIN_STOREUPS: {
VectorType *v4f32 = VectorType::get(Type::getFloatTy(Context), 4);
- PointerType *v4f32Ptr = PointerType::getUnqual(v4f32);
+ const PointerType *v4f32Ptr = v4f32->getPointerTo();
Value *BC = Builder.CreateBitCast(Ops[0], v4f32Ptr);
StoreInst *SI = Builder.CreateStore(Ops[1], BC);
SI->setAlignment(1);
@@ -327,7 +327,7 @@
}
case IX86_BUILTIN_STOREUPD: {
VectorType *v2f64 = VectorType::get(Type::getDoubleTy(Context), 2);
- PointerType *v2f64Ptr = PointerType::getUnqual(v2f64);
+ const PointerType *v2f64Ptr = v2f64->getPointerTo();
Value *BC = Builder.CreateBitCast(Ops[0], v2f64Ptr);
StoreInst *SI = Builder.CreateStore(Ops[1], BC);
SI->setAlignment(1);
@@ -336,7 +336,7 @@
}
case IX86_BUILTIN_STOREDQU: {
VectorType *v16i8 = VectorType::get(Type::getInt8Ty(Context), 16);
- PointerType *v16i8Ptr = PointerType::getUnqual(v16i8);
+ const PointerType *v16i8Ptr = v16i8->getPointerTo();
Value *BC = Builder.CreateBitCast(Ops[0], v16i8Ptr);
StoreInst *SI = Builder.CreateStore(Ops[1], BC);
SI->setAlignment(1);
@@ -344,7 +344,7 @@
return true;
}
case IX86_BUILTIN_LOADHPS: {
- PointerType *f64Ptr = PointerType::getUnqual(Type::getDoubleTy(Context));
+ const PointerType *f64Ptr = Type::getDoublePtrTy(Context);
Ops[1] = Builder.CreateBitCast(Ops[1], f64Ptr);
Value *Load = Builder.CreateLoad(Ops[1]);
Ops[1] = BuildVector(Load, UndefValue::get(Type::getDoubleTy(Context)), NULL);
@@ -354,7 +354,7 @@
return true;
}
case IX86_BUILTIN_LOADLPS: {
- PointerType *f64Ptr = PointerType::getUnqual(Type::getDoubleTy(Context));
+ const PointerType *f64Ptr = Type::getDoublePtrTy(Context);
Ops[1] = Builder.CreateBitCast(Ops[1], f64Ptr);
Value *Load = Builder.CreateLoad(Ops[1]);
Ops[1] = BuildVector(Load, UndefValue::get(Type::getDoubleTy(Context)), NULL);
@@ -381,7 +381,7 @@
}
case IX86_BUILTIN_STOREHPS: {
VectorType *v2f64 = VectorType::get(Type::getDoubleTy(Context), 2);
- PointerType *f64Ptr = PointerType::getUnqual(Type::getDoubleTy(Context));
+ const PointerType *f64Ptr = Type::getDoublePtrTy(Context);
Ops[0] = Builder.CreateBitCast(Ops[0], f64Ptr);
Value *Idx = ConstantInt::get(Type::getInt32Ty(Context), 1);
Ops[1] = Builder.CreateBitCast(Ops[1], v2f64);
@@ -391,7 +391,7 @@
}
case IX86_BUILTIN_STORELPS: {
VectorType *v2f64 = VectorType::get(Type::getDoubleTy(Context), 2);
- PointerType *f64Ptr = PointerType::getUnqual(Type::getDoubleTy(Context));
+ const PointerType *f64Ptr = Type::getDoublePtrTy(Context);
Ops[0] = Builder.CreateBitCast(Ops[0], f64Ptr);
Value *Idx = ConstantInt::get(Type::getInt32Ty(Context), 0);
Ops[1] = Builder.CreateBitCast(Ops[1], v2f64);
@@ -592,8 +592,7 @@
Intrinsic::getDeclaration(TheModule, Intrinsic::x86_sse_ldmxcsr);
Value *Ptr = CreateTemporary(Type::getInt32Ty(Context));
Builder.CreateStore(Ops[0], Ptr);
- Ptr = Builder.CreateBitCast(Ptr,
- PointerType::getUnqual(Type::getInt8Ty(Context)));
+ Ptr = Builder.CreateBitCast(Ptr, Type::getInt8PtrTy(Context));
Result = Builder.CreateCall(ldmxcsr, Ptr);
return true;
}
@@ -601,8 +600,7 @@
Function *stmxcsr =
Intrinsic::getDeclaration(TheModule, Intrinsic::x86_sse_stmxcsr);
Value *Ptr = CreateTemporary(Type::getInt32Ty(Context));
- Value *BPtr = Builder.CreateBitCast(Ptr,
- PointerType::getUnqual(Type::getInt8Ty(Context)));
+ Value *BPtr = Builder.CreateBitCast(Ptr, Type::getInt8PtrTy(Context));
Builder.CreateCall(stmxcsr, BPtr);
Result = Builder.CreateLoad(Ptr);
Modified: llvm-gcc-4.2/trunk/gcc/llvm-abi.h
URL: http://llvm.org/viewvc/llvm-project/llvm-gcc-4.2/trunk/gcc/llvm-abi.h?rev=83876&r1=83875&r2=83876&view=diff
==============================================================================
--- llvm-gcc-4.2/trunk/gcc/llvm-abi.h (original)
+++ llvm-gcc-4.2/trunk/gcc/llvm-abi.h Mon Oct 12 14:35:13 2009
@@ -390,7 +390,7 @@
if (ScalarType)
C.HandleAggregateResultAsScalar(ConvertType(ScalarType));
else if (LLVM_SHOULD_RETURN_VECTOR_AS_SHADOW(type, isBuiltin))
- C.HandleScalarShadowResult(PointerType::getUnqual(Ty), false);
+ C.HandleScalarShadowResult(Ty->getPointerTo(), false);
else
C.HandleScalarResult(Ty);
} else if (Ty->isSingleValueType() || Ty == Type::getVoidTy(getGlobalContext())) {
@@ -422,7 +422,7 @@
// FIXME: should return the hidden first argument for some targets
// (e.g. ELF i386).
- C.HandleAggregateShadowResult(PointerType::getUnqual(Ty), false);
+ C.HandleAggregateShadowResult(Ty->getPointerTo(), false);
}
}
@@ -445,7 +445,7 @@
C.HandleScalarArgument(OpTy, type);
ScalarElts.push_back(OpTy);
} else if (isPassedByInvisibleReference(type)) { // variable size -> by-ref.
- const Type *PtrTy = PointerType::getUnqual(Ty);
+ const Type *PtrTy = Ty->getPointerTo();
C.HandleByInvisibleReferenceArgument(PtrTy, type);
ScalarElts.push_back(PtrTy);
} else if (isa(Ty)) {
@@ -746,7 +746,7 @@
if (ScalarType)
C.HandleAggregateResultAsScalar(ConvertType(ScalarType));
else if (LLVM_SHOULD_RETURN_VECTOR_AS_SHADOW(type, isBuiltin))
- C.HandleScalarShadowResult(PointerType::getUnqual(Ty), false);
+ C.HandleScalarShadowResult(Ty->getPointerTo(), false);
else
C.HandleScalarResult(Ty);
} else if (Ty->isSingleValueType() || Ty == Type::getVoidTy(getGlobalContext())) {
@@ -778,7 +778,7 @@
// FIXME: should return the hidden first argument for some targets
// (e.g. ELF i386).
- C.HandleAggregateShadowResult(PointerType::getUnqual(Ty), false);
+ C.HandleAggregateShadowResult(Ty->getPointerTo(), false);
}
}
@@ -812,7 +812,7 @@
// not include variable sized fields here.
std::vector Elts;
if (isPassedByInvisibleReference(type)) { // variable size -> by-ref.
- const Type *PtrTy = PointerType::getUnqual(Ty);
+ const Type *PtrTy = Ty->getPointerTo();
C.HandleByInvisibleReferenceArgument(PtrTy, type);
ScalarElts.push_back(PtrTy);
Modified: llvm-gcc-4.2/trunk/gcc/llvm-backend.cpp
URL: http://llvm.org/viewvc/llvm-project/llvm-gcc-4.2/trunk/gcc/llvm-backend.cpp?rev=83876&r1=83875&r2=83876&view=diff
==============================================================================
--- llvm-gcc-4.2/trunk/gcc/llvm-backend.cpp (original)
+++ llvm-gcc-4.2/trunk/gcc/llvm-backend.cpp Mon Oct 12 14:35:13 2009
@@ -822,7 +822,7 @@
const Type *FPTy =
FunctionType::get(Type::getVoidTy(Context),
std::vector(), false);
- FPTy = PointerType::getUnqual(FPTy);
+ FPTy = FPTy->getPointerTo();
for (unsigned i = 0, e = Tors.size(); i != e; ++i) {
StructInit[0] = ConstantInt::get(Type::getInt32Ty(Context), Tors[i].second);
@@ -861,7 +861,7 @@
if (!AttributeUsedGlobals.empty()) {
std::vector AUGs;
- const Type *SBP= PointerType::getUnqual(Type::getInt8Ty(Context));
+ const Type *SBP= Type::getInt8PtrTy(Context);
for (SmallSetVector::iterator
AI = AttributeUsedGlobals.begin(),
AE = AttributeUsedGlobals.end(); AI != AE; ++AI) {
@@ -880,7 +880,7 @@
if (!AttributeCompilerUsedGlobals.empty()) {
std::vector ACUGs;
- const Type *SBP= PointerType::getUnqual(Type::getInt8Ty(Context));
+ const Type *SBP= Type::getInt8PtrTy(Context);
for (SmallSetVector::iterator
AI = AttributeCompilerUsedGlobals.begin(),
AE = AttributeCompilerUsedGlobals.end(); AI != AE; ++AI) {
@@ -1158,7 +1158,7 @@
Constant *lineNo = ConstantInt::get(Type::getInt32Ty(Context),
DECL_SOURCE_LINE(decl));
Constant *file = ConvertMetadataStringToGV(DECL_SOURCE_FILE(decl));
- const Type *SBP= PointerType::getUnqual(Type::getInt8Ty(Context));
+ const Type *SBP= Type::getInt8PtrTy(Context);
file = TheFolder->CreateBitCast(file, SBP);
// There may be multiple annotate attributes. Pass return of lookup_attr
Modified: llvm-gcc-4.2/trunk/gcc/llvm-convert.cpp
URL: http://llvm.org/viewvc/llvm-project/llvm-gcc-4.2/trunk/gcc/llvm-convert.cpp?rev=83876&r1=83875&r2=83876&view=diff
==============================================================================
--- llvm-gcc-4.2/trunk/gcc/llvm-convert.cpp (original)
+++ llvm-gcc-4.2/trunk/gcc/llvm-convert.cpp Mon Oct 12 14:35:13 2009
@@ -229,7 +229,7 @@
Builder.CreateStore(ArgVal, Loc);
} else {
// This cast only involves pointers, therefore BitCast.
- Loc = Builder.CreateBitCast(Loc, PointerType::getUnqual(LLVMTy));
+ Loc = Builder.CreateBitCast(Loc, LLVMTy->getPointerTo());
Builder.CreateStore(ArgVal, Loc);
}
}
@@ -374,7 +374,7 @@
Value *Loc = LocStack.back();
// This cast only involves pointers, therefore BitCast.
- Loc = Builder.CreateBitCast(Loc, PointerType::getUnqual(StructTy));
+ Loc = Builder.CreateBitCast(Loc, StructTy->getPointerTo());
Loc = Builder.CreateStructGEP(Loc, FieldNo);
LocStack.push_back(Loc);
@@ -665,7 +665,7 @@
} else {
Value *RetVal = DECL_LLVM(DECL_RESULT(FnDecl));
if (const StructType *STy = dyn_cast(Fn->getReturnType())) {
- Value *R1 = BitCastToType(RetVal, PointerType::getUnqual(STy));
+ Value *R1 = BitCastToType(RetVal, STy->getPointerTo());
llvm::Value *Idxs[2];
Idxs[0] = ConstantInt::get(llvm::Type::getInt32Ty(Context), 0);
@@ -683,12 +683,11 @@
// beginning of the aggregate (x86-64).
if (ReturnOffset) {
RetVal = BitCastToType(RetVal,
- PointerType::getUnqual(Type::getInt8Ty(Context)));
+ Type::getInt8PtrTy(Context));
RetVal = Builder.CreateGEP(RetVal,
ConstantInt::get(TD.getIntPtrType(Context), ReturnOffset));
}
- RetVal = BitCastToType(RetVal,
- PointerType::getUnqual(Fn->getReturnType()));
+ RetVal = BitCastToType(RetVal, Fn->getReturnType()->getPointerTo());
RetVal = Builder.CreateLoad(RetVal, "retval");
RetVals.push_back(RetVal);
}
@@ -1340,9 +1339,9 @@
// Don't copy tons of tiny elements.
NumElts <= 8) {
DestLoc.Ptr = BitCastToType(DestLoc.Ptr,
- PointerType::getUnqual(LLVMTy));
+ LLVMTy->getPointerTo());
SrcLoc.Ptr = BitCastToType(SrcLoc.Ptr,
- PointerType::getUnqual(LLVMTy));
+ LLVMTy->getPointerTo());
CopyAggregate(DestLoc, SrcLoc, Builder, type);
return;
}
@@ -1395,7 +1394,7 @@
// Don't zero tons of tiny elements.
CountAggregateElements(LLVMTy) <= 8) {
DestLoc.Ptr = BitCastToType(DestLoc.Ptr,
- PointerType::getUnqual(LLVMTy));
+ LLVMTy->getPointerTo());
ZeroAggregate(DestLoc, Builder);
return;
}
@@ -1407,7 +1406,7 @@
Value *TreeToLLVM::EmitMemCpy(Value *DestPtr, Value *SrcPtr, Value *Size,
unsigned Align) {
- const Type *SBP = PointerType::getUnqual(Type::getInt8Ty(Context));
+ const Type *SBP = Type::getInt8PtrTy(Context);
const Type *IntPtr = TD.getIntPtrType(Context);
Value *Ops[4] = {
BitCastToType(DestPtr, SBP),
@@ -1423,7 +1422,7 @@
Value *TreeToLLVM::EmitMemMove(Value *DestPtr, Value *SrcPtr, Value *Size,
unsigned Align) {
- const Type *SBP = PointerType::getUnqual(Type::getInt8Ty(Context));
+ const Type *SBP = Type::getInt8PtrTy(Context);
const Type *IntPtr = TD.getIntPtrType(Context);
Value *Ops[4] = {
BitCastToType(DestPtr, SBP),
@@ -1439,7 +1438,7 @@
Value *TreeToLLVM::EmitMemSet(Value *DestPtr, Value *SrcVal, Value *Size,
unsigned Align) {
- const Type *SBP = PointerType::getUnqual(Type::getInt8Ty(Context));
+ const Type *SBP = Type::getInt8PtrTy(Context);
const Type *IntPtr = TD.getIntPtrType(Context);
Value *Ops[4] = {
BitCastToType(DestPtr, SBP),
@@ -1464,8 +1463,8 @@
// The idea is that it's a pointer to type "Value"
// which is opaque* but the routine expects i8** and i8*.
- const PointerType *Ty = PointerType::getUnqual(Type::getInt8Ty(Context));
- V = Builder.CreateBitCast(V, PointerType::getUnqual(Ty));
+ const PointerType *Ty = Type::getInt8PtrTy(Context);
+ V = Builder.CreateBitCast(V, Ty->getPointerTo());
Value *Ops[2] = {
V,
@@ -1491,7 +1490,7 @@
Constant *lineNo =
ConstantInt::get(Type::getInt32Ty(Context), DECL_SOURCE_LINE(decl));
Constant *file = ConvertMetadataStringToGV(DECL_SOURCE_FILE(decl));
- const Type *SBP= PointerType::getUnqual(Type::getInt8Ty(Context));
+ const Type *SBP= Type::getInt8PtrTy(Context);
file = Builder.getFolder().CreateBitCast(file, SBP);
// There may be multiple annotate attributes. Pass return of lookup_attr
@@ -1511,7 +1510,7 @@
// Assert its a string, and then get that string.
assert(TREE_CODE(val) == STRING_CST &&
"Annotate attribute arg should always be a string");
- const Type *SBP = PointerType::getUnqual(Type::getInt8Ty(Context));
+ const Type *SBP = Type::getInt8PtrTy(Context);
Constant *strGV = TreeConstantToLLVM::EmitLV_STRING_CST(val);
Value *Ops[4] = {
BitCastToType(V, SBP),
@@ -1919,7 +1918,7 @@
const Type *IntPtr = TD.getIntPtrType(Context);
- ExceptionValue = CreateTemporary(PointerType::getUnqual(Type::getInt8Ty(Context)));
+ ExceptionValue = CreateTemporary(Type::getInt8PtrTy(Context));
ExceptionValue->setName("eh_exception");
ExceptionSelectorValue = CreateTemporary(IntPtr);
@@ -1981,7 +1980,7 @@
assert(llvm_eh_personality_libfunc
&& "no exception handling personality function!");
Args.push_back(BitCastToType(DECL_LLVM(llvm_eh_personality_libfunc),
- PointerType::getUnqual(Type::getInt8Ty(Context))));
+ Type::getInt8PtrTy(Context)));
// Add selections for each handler.
foreach_reachable_handler(i, false, AddHandler, &Handlers);
@@ -2013,7 +2012,7 @@
if (!TypeList) {
// Catch-all - push a null pointer.
Args.push_back(
- Constant::getNullValue(PointerType::getUnqual(Type::getInt8Ty(Context)))
+ Constant::getNullValue(Type::getInt8PtrTy(Context))
);
} else {
// Add the type infos.
@@ -2040,7 +2039,7 @@
if (catch_all_type == NULL_TREE)
// Use a C++ style null catch-all object.
CatchAll = Constant::getNullValue(
- PointerType::getUnqual(Type::getInt8Ty(Context)));
+ Type::getInt8PtrTy(Context));
else
// This language has a type that catches all others.
CatchAll = Emit(catch_all_type, 0);
@@ -2104,7 +2103,7 @@
for (; TypeList; TypeList = TREE_CHAIN (TypeList)) {
Value *TType = Emit(lookup_type_for_runtime(TREE_VALUE(TypeList)), 0);
TType = BitCastToType(TType,
- PointerType::getUnqual(Type::getInt8Ty(Context)));
+ Type::getInt8PtrTy(Context));
// Call get eh type id.
Value *TypeID = Builder.CreateCall(FuncEHGetTypeID, TType, "eh_typeid");
@@ -2262,7 +2261,7 @@
if (!LV.isBitfield()) {
if (!DestLoc) {
// Scalar value: emit a load.
- Value *Ptr = BitCastToType(LV.Ptr, PointerType::getUnqual(Ty));
+ Value *Ptr = BitCastToType(LV.Ptr, Ty->getPointerTo());
LoadInst *LI = Builder.CreateLoad(Ptr, isVolatile);
LI->setAlignment(Alignment);
return LI;
@@ -2391,7 +2390,7 @@
// If this is a direct call to a function using a static chain then we need
// to ensure the function type is the one just calculated: it has an extra
// parameter for the chain.
- Callee = BitCastToType(Callee, PointerType::getUnqual(Ty));
+ Callee = BitCastToType(Callee, Ty->getPointerTo());
// EmitCall(exp, DestLoc);
Value *Result = EmitCallOf(Callee, exp, DestLoc, PAL);
@@ -2496,7 +2495,7 @@
Value *Loc = LocStack.back();
if (Loc) {
// An address. Convert to the right type and load the value out.
- Loc = Builder.CreateBitCast(Loc, PointerType::getUnqual(Ty));
+ Loc = Builder.CreateBitCast(Loc, Ty->getPointerTo());
return Builder.CreateLoad(Loc, "val");
} else {
// A value - just return it.
@@ -2639,7 +2638,7 @@
/// reference with an additional parameter attribute "ByVal".
void HandleByValArgument(const llvm::Type *LLVMTy, tree type) {
Value *Loc = getAddress();
- assert(PointerType::getUnqual(LLVMTy) == Loc->getType());
+ assert(LLVMTy->getPointerTo() == Loc->getType());
CallOperands.push_back(Loc);
}
@@ -2647,7 +2646,7 @@
/// argument is passed as a first class aggregate.
void HandleFCAArgument(const llvm::Type *LLVMTy, tree type) {
Value *Loc = getAddress();
- assert(PointerType::getUnqual(LLVMTy) == Loc->getType());
+ assert(LLVMTy->getPointerTo() == Loc->getType());
CallOperands.push_back(Builder.CreateLoad(Loc));
}
@@ -2656,7 +2655,7 @@
/// LLVM Struct, StructTy is the LLVM type of the struct we are entering.
void EnterField(unsigned FieldNo, const llvm::Type *StructTy) {
Value *Loc = getAddress();
- Loc = Builder.CreateBitCast(Loc, PointerType::getUnqual(StructTy));
+ Loc = Builder.CreateBitCast(Loc, StructTy->getPointerTo());
pushAddress(Builder.CreateStructGEP(Loc, FieldNo, "elt"));
}
void ExitField() {
@@ -2816,8 +2815,7 @@
return 0;
if (Client.isAggrReturn()) {
- Value *Dest = BitCastToType(DestLoc->Ptr,
- PointerType::getUnqual(Call->getType()));
+ Value *Dest = BitCastToType(DestLoc->Ptr, Call->getType()->getPointerTo());
LLVM_EXTRACT_MULTIPLE_RETURN_VALUE(Call,Dest,DestLoc->Volatile,Builder);
return 0;
}
@@ -2833,11 +2831,11 @@
Value *Ptr = DestLoc->Ptr;
if (Client.Offset) {
- Ptr = BitCastToType(Ptr, PointerType::getUnqual(Type::getInt8Ty(Context)));
+ Ptr = BitCastToType(Ptr, Type::getInt8PtrTy(Context));
Ptr = Builder.CreateGEP(Ptr,
ConstantInt::get(TD.getIntPtrType(Context), Client.Offset));
}
- Ptr = BitCastToType(Ptr, PointerType::getUnqual(Call->getType()));
+ Ptr = BitCastToType(Ptr, Call->getType()->getPointerTo());
StoreInst *St = Builder.CreateStore(Call, Ptr, DestLoc->Volatile);
St->setAlignment(DestLoc->getAlignment());
return 0;
@@ -2967,8 +2965,7 @@
if (PT->getElementType()->canLosslesslyBitCastTo(RHS->getType()))
RHS = CastToAnyType(RHS, RHSSigned, PT->getElementType(), LHSSigned);
else
- LV.Ptr = BitCastToType(LV.Ptr,
- PointerType::getUnqual(RHS->getType()));
+ LV.Ptr = BitCastToType(LV.Ptr, RHS->getType()->getPointerTo());
StoreInst *SI = Builder.CreateStore(RHS, LV.Ptr, isVolatile);
SI->setAlignment(Alignment);
return RHS;
@@ -3080,7 +3077,7 @@
} else if (isAggregateTreeType(TREE_TYPE(Op))) {
// Aggregate to aggregate copy.
MemRef NewLoc = *DestLoc;
- NewLoc.Ptr = BitCastToType(DestLoc->Ptr, PointerType::getUnqual(Ty));
+ NewLoc.Ptr = BitCastToType(DestLoc->Ptr, Ty->getPointerTo());
Value *OpVal = Emit(Op, &NewLoc);
assert(OpVal == 0 && "Shouldn't cast scalar to aggregate!");
return 0;
@@ -3088,8 +3085,7 @@
// Scalar to aggregate copy.
Value *OpVal = Emit(Op, 0);
- Value *Ptr = BitCastToType(DestLoc->Ptr,
- PointerType::getUnqual(OpVal->getType()));
+ Value *Ptr = BitCastToType(DestLoc->Ptr, OpVal->getType()->getPointerTo());
StoreInst *St = Builder.CreateStore(OpVal, Ptr, DestLoc->Volatile);
St->setAlignment(DestLoc->getAlignment());
return 0;
@@ -3117,7 +3113,7 @@
// Make the destination look like the source type.
const Type *OpTy = ConvertType(TREE_TYPE(Op));
- Target.Ptr = BitCastToType(Target.Ptr, PointerType::getUnqual(OpTy));
+ Target.Ptr = BitCastToType(Target.Ptr, OpTy->getPointerTo());
// Needs to be in sync with EmitLV.
switch (TREE_CODE(Op)) {
@@ -3157,7 +3153,7 @@
// Target holds the temporary created above.
const Type *ExpTy = ConvertType(TREE_TYPE(exp));
return Builder.CreateLoad(BitCastToType(Target.Ptr,
- PointerType::getUnqual(ExpTy)));
+ ExpTy->getPointerTo()));
}
if (DestLoc) {
@@ -3165,8 +3161,7 @@
// then store into DestLoc.
Value *OpVal = Emit(Op, 0);
assert(OpVal && "Expected a scalar result!");
- Value *Ptr = BitCastToType(DestLoc->Ptr,
- PointerType::getUnqual(OpVal->getType()));
+ Value *Ptr = BitCastToType(DestLoc->Ptr, OpVal->getType()->getPointerTo());
StoreInst *St = Builder.CreateStore(OpVal, Ptr, DestLoc->Volatile);
St->setAlignment(DestLoc->getAlignment());
return 0;
@@ -4478,7 +4473,7 @@
TySize == 32 || TySize == 64) {
LLVMTy = IntegerType::get(Context, TySize);
Op = Builder.CreateLoad(BitCastToType(LV.Ptr,
- PointerType::getUnqual(LLVMTy)));
+ LLVMTy->getPointerTo()));
} else {
// Otherwise, emit our value as a lvalue and let the codegen deal with
// it.
@@ -4811,7 +4806,7 @@
};
const Type* Ty[2];
Ty[0] = ResultTy;
- Ty[1] = PointerType::getUnqual(ResultTy);
+ Ty[1] = ResultTy->getPointerTo();
C[0] = Builder.CreateBitCast(C[0], Ty[1]);
C[1] = Builder.CreateIntCast(C[1], Ty[0], "cast");
// The gcc builtins are also full memory barriers.
@@ -4836,7 +4831,7 @@
};
const Type* Ty[2];
Ty[0] = ResultTy;
- Ty[1] = PointerType::getUnqual(ResultTy);
+ Ty[1] = ResultTy->getPointerTo();
C[0] = Builder.CreateBitCast(C[0], Ty[1]);
C[1] = Builder.CreateIntCast(C[1], Ty[0], "cast");
C[2] = Builder.CreateIntCast(C[2], Ty[0], "cast");
@@ -5145,7 +5140,7 @@
location_t locus = EXPR_LOCATION (exp);
Constant *lineNo = ConstantInt::get(Type::getInt32Ty(Context), locus.line);
Constant *file = ConvertMetadataStringToGV(locus.file);
- const Type *SBP= PointerType::getUnqual(Type::getInt8Ty(Context));
+ const Type *SBP= Type::getInt8PtrTy(Context);
file = Builder.getFolder().CreateBitCast(file, SBP);
// Get arguments.
@@ -5318,7 +5313,7 @@
};
const Type* Ty[2];
Ty[0] = ResultTy;
- Ty[1] = PointerType::getUnqual(ResultTy);
+ Ty[1] = ResultTy->getPointerTo();
C[0] = Builder.CreateBitCast(C[0], Ty[1]);
C[1] = Builder.CreateIntCast(C[1], Ty[0], "cast");
@@ -5356,7 +5351,7 @@
};
const Type* Ty[2];
Ty[0] = ResultTy;
- Ty[1] = PointerType::getUnqual(ResultTy);
+ Ty[1] = ResultTy->getPointerTo();
C[0] = Builder.CreateBitCast(C[0], Ty[1]);
C[1] = Builder.CreateIntCast(C[1], Ty[0], "cast");
@@ -5394,7 +5389,7 @@
};
const Type* Ty[2];
Ty[0] = ResultTy;
- Ty[1] = PointerType::getUnqual(ResultTy);
+ Ty[1] = ResultTy->getPointerTo();
C[0] = Builder.CreateBitCast(C[0], Ty[1]);
C[1] = Builder.CreateIntCast(C[1], Ty[0], "cast");
@@ -5432,7 +5427,7 @@
};
const Type* Ty[2];
Ty[0] = ResultTy;
- Ty[1] = PointerType::getUnqual(ResultTy);
+ Ty[1] = ResultTy->getPointerTo();
C[0] = Builder.CreateBitCast(C[0], Ty[1]);
C[1] = Builder.CreateIntCast(C[1], Ty[0], "cast");
@@ -5470,7 +5465,7 @@
};
const Type* Ty[2];
Ty[0] = ResultTy;
- Ty[1] = PointerType::getUnqual(ResultTy);
+ Ty[1] = ResultTy->getPointerTo();
C[0] = Builder.CreateBitCast(C[0], Ty[1]);
C[1] = Builder.CreateIntCast(C[1], Ty[0], "cast");
@@ -5508,7 +5503,7 @@
};
const Type* Ty[2];
Ty[0] = ResultTy;
- Ty[1] = PointerType::getUnqual(ResultTy);
+ Ty[1] = ResultTy->getPointerTo();
C[0] = Builder.CreateBitCast(C[0], Ty[1]);
C[1] = Builder.CreateIntCast(C[1], Ty[0], "cast");
@@ -5828,7 +5823,7 @@
if (Locality == 0)
Locality = ConstantInt::get(Type::getInt32Ty(Context), 3);
- Ptr = BitCastToType(Ptr, PointerType::getUnqual(Type::getInt8Ty(Context)));
+ Ptr = BitCastToType(Ptr, Type::getInt8PtrTy(Context));
Value *Ops[3] = { Ptr, ReadWrite, Locality };
Builder.CreateCall(Intrinsic::getDeclaration(TheModule, Intrinsic::prefetch),
@@ -5871,7 +5866,7 @@
// Unfortunately, these constants are defined as RTL expressions and
// should be handled separately.
- Result = BitCastToType(Ptr, PointerType::getUnqual(Type::getInt8Ty(Context)));
+ Result = BitCastToType(Ptr, Type::getInt8PtrTy(Context));
return true;
}
@@ -5887,7 +5882,7 @@
// needed for: MIPS, Sparc. Unfortunately, these constants are defined
// as RTL expressions and should be handled separately.
- Result = BitCastToType(Ptr, PointerType::getUnqual(Type::getInt8Ty(Context)));
+ Result = BitCastToType(Ptr, Type::getInt8PtrTy(Context));
return true;
}
@@ -5995,7 +5990,7 @@
Intrinsic::eh_return_i32 : Intrinsic::eh_return_i64);
Offset = Builder.CreateIntCast(Offset, IntPtr, true);
- Handler = BitCastToType(Handler, PointerType::getUnqual(Type::getInt8Ty(Context)));
+ Handler = BitCastToType(Handler, Type::getInt8PtrTy(Context));
SmallVector Args;
Args.push_back(Offset);
@@ -6024,7 +6019,7 @@
}
Value *Addr = BitCastToType(Emit(TREE_VALUE(arglist), 0),
- PointerType::getUnqual(Type::getInt8Ty(Context)));
+ Type::getInt8PtrTy(Context));
Constant *Size, *Idx;
for (i = 0; i < FIRST_PSEUDO_REGISTER; i++) {
@@ -6086,7 +6081,7 @@
return false;
Value *Ptr = Emit(TREE_VALUE(arglist), 0);
- Ptr = BitCastToType(Ptr, PointerType::getUnqual(Type::getInt8Ty(Context)));
+ Ptr = BitCastToType(Ptr, Type::getInt8PtrTy(Context));
Builder.CreateCall(Intrinsic::getDeclaration(TheModule,
Intrinsic::stackrestore), Ptr);
@@ -6135,14 +6130,14 @@
Constant *llvm_va_start_fn = Intrinsic::getDeclaration(TheModule,
Intrinsic::vastart);
- ArgVal = BitCastToType(ArgVal, PointerType::getUnqual(Type::getInt8Ty(Context)));
+ ArgVal = BitCastToType(ArgVal, Type::getInt8PtrTy(Context));
Builder.CreateCall(llvm_va_start_fn, ArgVal);
return true;
}
bool TreeToLLVM::EmitBuiltinVAEnd(tree exp) {
Value *Arg = Emit(TREE_VALUE(TREE_OPERAND(exp, 1)), 0);
- Arg = BitCastToType(Arg, PointerType::getUnqual(Type::getInt8Ty(Context)));
+ Arg = BitCastToType(Arg, Type::getInt8PtrTy(Context));
Builder.CreateCall(Intrinsic::getDeclaration(TheModule, Intrinsic::vaend),
Arg);
return true;
@@ -6167,7 +6162,7 @@
Arg2 = Emit(Arg2T, 0);
}
- static const Type *VPTy = PointerType::getUnqual(Type::getInt8Ty(Context));
+ static const Type *VPTy = Type::getInt8PtrTy(Context);
// FIXME: This ignores alignment and volatility of the arguments.
SmallVector Args;
@@ -6185,7 +6180,7 @@
VOID_TYPE))
return false;
- static const Type *VPTy = PointerType::getUnqual(Type::getInt8Ty(Context));
+ static const Type *VPTy = Type::getInt8PtrTy(Context);
Value *Tramp = Emit(TREE_VALUE(arglist), 0);
Tramp = BitCastToType(Tramp, VPTy);
@@ -6379,7 +6374,7 @@
Value *TreeToLLVM::EmitFieldAnnotation(Value *FieldPtr, tree FieldDecl) {
tree AnnotateAttr = lookup_attribute("annotate", DECL_ATTRIBUTES(FieldDecl));
- const Type *SBP = PointerType::getUnqual(Type::getInt8Ty(Context));
+ const Type *SBP = Type::getInt8PtrTy(Context);
Function *Fn = Intrinsic::getDeclaration(TheModule,
Intrinsic::ptr_annotation,
@@ -6500,7 +6495,7 @@
const Type *ElementTy = ConvertType(ElementType);
unsigned Alignment = MinAlign(ArrayAlign, TD.getABITypeAlignment(ElementTy));
return LValue(BitCastToType(Ptr,
- PointerType::getUnqual(ConvertType(TREE_TYPE(exp)))),
+ ConvertType(TREE_TYPE(exp))->getPointerTo()),
Alignment);
}
@@ -6509,7 +6504,7 @@
// float foo(int w, float A[][w], int g) { return A[g][0]; }
ArrayAddr = BitCastToType(ArrayAddr,
- PointerType::getUnqual(Type::getInt8Ty(Context)));
+ Type::getInt8PtrTy(Context));
if (VOID_TYPE_P(TREE_TYPE(ArrayTreeType)))
return LValue(Builder.CreateGEP(ArrayAddr, IndexVal), 1);
@@ -6523,8 +6518,7 @@
Value *Ptr = flag_wrapv ?
Builder.CreateGEP(ArrayAddr, IndexVal) :
Builder.CreateInBoundsGEP(ArrayAddr, IndexVal);
- return LValue(BitCastToType(Ptr,
- PointerType::getUnqual(ConvertType(TREE_TYPE(exp)))),
+ return LValue(BitCastToType(Ptr, ConvertType(TREE_TYPE(exp))->getPointerTo()),
Alignment);
}
@@ -6550,7 +6544,7 @@
if (unsigned UnitOffset = BitStart / ValueSizeInBits) {
// TODO: If Ptr.Ptr is a struct type or something, we can do much better
// than this. e.g. check out when compiling unwind-dw2-fde-darwin.c.
- Ptr.Ptr = BitCastToType(Ptr.Ptr, PointerType::getUnqual(ValTy));
+ Ptr.Ptr = BitCastToType(Ptr.Ptr, ValTy->getPointerTo());
Ptr.Ptr = Builder.CreateGEP(Ptr.Ptr,
ConstantInt::get(Type::getInt32Ty(Context), UnitOffset));
BitStart -= UnitOffset*ValueSizeInBits;
@@ -6558,11 +6552,11 @@
// If this is referring to the whole field, return the whole thing.
if (BitStart == 0 && BitSize == ValueSizeInBits) {
- return LValue(BitCastToType(Ptr.Ptr, PointerType::getUnqual(ValTy)),
+ return LValue(BitCastToType(Ptr.Ptr, ValTy->getPointerTo()),
Ptr.getAlignment());
}
- return LValue(BitCastToType(Ptr.Ptr, PointerType::getUnqual(ValTy)), 1,
+ return LValue(BitCastToType(Ptr.Ptr, ValTy->getPointerTo()), 1,
BitStart, BitSize);
}
@@ -6585,7 +6579,7 @@
StructAddrLV.BitStart == 0) && "structs cannot be bitfields!");
StructAddrLV.Ptr = BitCastToType(StructAddrLV.Ptr,
- PointerType::getUnqual(StructTy));
+ StructTy->getPointerTo());
const Type *FieldTy = ConvertType(getDeclaredType(FieldDecl));
// BitStart - This is the actual offset of the field from the start of the
@@ -6662,7 +6656,7 @@
Offset->getType());
Ptr = Builder.CreateAdd(Ptr, Offset);
FieldPtr = CastToType(Instruction::IntToPtr, Ptr,
- PointerType::getUnqual(FieldTy));
+ FieldTy->getPointerTo());
}
if (isBitfield(FieldDecl)) {
@@ -6702,7 +6696,7 @@
// If this is a bitfield, the field may span multiple fields in the LLVM
// type. As such, cast the pointer to be a pointer to the declared type.
- FieldPtr = BitCastToType(FieldPtr, PointerType::getUnqual(FieldTy));
+ FieldPtr = BitCastToType(FieldPtr, FieldTy->getPointerTo());
unsigned LLVMValueBitSize = FieldTy->getPrimitiveSizeInBits();
// Finally, because bitfields can span LLVM fields, and because the start
@@ -6734,7 +6728,7 @@
Offset->getType());
FieldPtr = Builder.CreateAdd(FieldPtr, Offset);
FieldPtr = CastToType(Instruction::IntToPtr, FieldPtr,
- PointerType::getUnqual(FieldTy));
+ FieldTy->getPointerTo());
// Adjust bitstart to account for the pointer movement.
BitStart -= ByteOffset*8;
@@ -6755,7 +6749,7 @@
} else {
// Make sure we return a pointer to the right type.
const Type *EltTy = ConvertType(TREE_TYPE(exp));
- FieldPtr = BitCastToType(FieldPtr, PointerType::getUnqual(EltTy));
+ FieldPtr = BitCastToType(FieldPtr, EltTy->getPointerTo());
}
assert(BitStart == 0 &&
@@ -6796,7 +6790,7 @@
if (Decl == 0) {
if (errorcount || sorrycount) {
const Type *Ty = ConvertType(TREE_TYPE(exp));
- const PointerType *PTy = PointerType::getUnqual(Ty);
+ const PointerType *PTy = Ty->getPointerTo();
LValue LV(ConstantPointerNull::get(PTy), 1);
return LV;
}
@@ -6834,7 +6828,7 @@
// If we have "extern void foo", make the global have type {} instead of
// type void.
if (Ty == Type::getVoidTy(Context)) Ty = StructType::get(Context);
- const PointerType *PTy = PointerType::getUnqual(Ty);
+ const PointerType *PTy = Ty->getPointerTo();
unsigned Alignment = Ty->isSized() ? TD.getABITypeAlignment(Ty) : 1;
if (DECL_ALIGN(exp)) {
if (DECL_USER_ALIGN(exp) || 8 * Alignment < (unsigned)DECL_ALIGN(exp))
@@ -6850,7 +6844,7 @@
unsigned Alignment = TD.getABITypeAlignment(cast(ExceptionValue->
getType())->getElementType());
return LValue(BitCastToType(ExceptionValue,
- PointerType::getUnqual(ConvertType(TREE_TYPE(exp)))),
+ ConvertType(TREE_TYPE(exp))->getPointerTo()),
Alignment);
}
@@ -6878,16 +6872,14 @@
// If the input is an aggregate, the address is the address of the operand.
LValue LV = EmitLV(Op);
// The type is the type of the expression.
- LV.Ptr = BitCastToType(LV.Ptr,
- PointerType::getUnqual(ConvertType(TREE_TYPE(exp))));
+ LV.Ptr = BitCastToType(LV.Ptr, ConvertType(TREE_TYPE(exp))->getPointerTo());
return LV;
} else {
// If the input is a scalar, emit to a temporary.
Value *Dest = CreateTemporary(ConvertType(TREE_TYPE(Op)));
Builder.CreateStore(Emit(Op, 0), Dest);
// The type is the type of the expression.
- Dest = BitCastToType(Dest,
- PointerType::getUnqual(ConvertType(TREE_TYPE(exp))));
+ Dest = BitCastToType(Dest, ConvertType(TREE_TYPE(exp))->getPointerTo());
return LValue(Dest, 1);
}
}
@@ -6981,8 +6973,7 @@
} else {
// Scalar value. Evaluate to a register, then do the store.
Value *V = Emit(tree_value, 0);
- Value *Ptr = BitCastToType(DestLoc->Ptr,
- PointerType::getUnqual(V->getType()));
+ Value *Ptr = BitCastToType(DestLoc->Ptr, V->getType()->getPointerTo());
StoreInst *St = Builder.CreateStore(V, Ptr, DestLoc->Volatile);
St->setAlignment(DestLoc->getAlignment());
}
@@ -7990,7 +7981,7 @@
BasicBlock *BB = getLabelDeclBlock(exp);
Constant *C = TheTreeToLLVM->getIndirectGotoBlockNumber(BB);
return
- TheFolder->CreateIntToPtr(C, PointerType::getUnqual(Type::getInt8Ty(Context)));
+ TheFolder->CreateIntToPtr(C, Type::getInt8PtrTy(Context));
}
Constant *TreeConstantToLLVM::EmitLV_COMPLEX_CST(tree exp) {
@@ -8089,7 +8080,7 @@
tree FieldDecl = TREE_OPERAND(exp, 1);
StructAddrLV = TheFolder->CreateBitCast(StructAddrLV,
- PointerType::getUnqual(StructTy));
+ StructTy->getPointerTo());
const Type *FieldTy = ConvertType(getDeclaredType(FieldDecl));
// BitStart - This is the actual offset of the field from the start of the
@@ -8126,13 +8117,12 @@
Constant *Ptr = TheFolder->CreatePtrToInt(StructAddrLV, Offset->getType());
Ptr = TheFolder->CreateAdd(Ptr, Offset);
FieldPtr = TheFolder->CreateIntToPtr(Ptr,
- PointerType::getUnqual(FieldTy));
+ FieldTy->getPointerTo());
}
// Make sure we return a result of the right type.
- if (PointerType::getUnqual(FieldTy) != FieldPtr->getType())
- FieldPtr = TheFolder->CreateBitCast(FieldPtr,
- PointerType::getUnqual(FieldTy));
+ if (FieldTy->getPointerTo() != FieldPtr->getType())
+ FieldPtr = TheFolder->CreateBitCast(FieldPtr, FieldTy->getPointerTo());
assert(BitStart == 0 &&
"It's a bitfield reference or we didn't get to the field!");
Modified: llvm-gcc-4.2/trunk/gcc/llvm-types.cpp
URL: http://llvm.org/viewvc/llvm-project/llvm-gcc-4.2/trunk/gcc/llvm-types.cpp?rev=83876&r1=83875&r2=83876&view=diff
==============================================================================
--- llvm-gcc-4.2/trunk/gcc/llvm-types.cpp (original)
+++ llvm-gcc-4.2/trunk/gcc/llvm-types.cpp Mon Oct 12 14:35:13 2009
@@ -822,8 +822,7 @@
Ty = GET_TYPE_LLVM(TYPE_MAIN_VARIANT(TREE_TYPE(type)));
if (Ty == 0) {
PointersToReresolve.push_back(type);
- return TypeDB.setType(type,
- PointerType::getUnqual(OpaqueType::get(Context)));
+ return TypeDB.setType(type, OpaqueType::get(Context)->getPointerTo());
}
// A type has already been computed. However, this may be some sort of
@@ -841,7 +840,7 @@
if (Ty == Type::getVoidTy(Context))
Ty = Type::getInt8Ty(Context); // void* -> sbyte*
- return TypeDB.setType(type, PointerType::getUnqual(Ty));
+ return TypeDB.setType(type, Ty->getPointerTo());
}
case METHOD_TYPE:
@@ -1014,7 +1013,7 @@
/// argument is passed by value. It is lowered to a parameter passed by
/// reference with an additional parameter attribute "ByVal".
void HandleByValArgument(const llvm::Type *LLVMTy, tree type) {
- HandleScalarArgument(PointerType::getUnqual(LLVMTy), type);
+ HandleScalarArgument(LLVMTy->getPointerTo(), type);
}
/// HandleFCAArgument - This callback is invoked if the aggregate function
From baldrick at free.fr Mon Oct 12 14:36:17 2009
From: baldrick at free.fr (Duncan Sands)
Date: Mon, 12 Oct 2009 19:36:17 -0000
Subject: [llvm-commits] [llvm-gcc-4.2] r83877 -
/llvm-gcc-4.2/trunk/gcc/llvm-backend.cpp
Message-ID: <200910121936.n9CJaHo3021624@zion.cs.uiuc.edu>
Author: baldrick
Date: Mon Oct 12 14:36:16 2009
New Revision: 83877
URL: http://llvm.org/viewvc/llvm-project?rev=83877&view=rev
Log:
Port of dragonegg commit 83374: Map GCC's -fverbose-asm to --asm-verbose,
rather than mapping -dA as now, since this seems more logical.
Modified:
llvm-gcc-4.2/trunk/gcc/llvm-backend.cpp
Modified: llvm-gcc-4.2/trunk/gcc/llvm-backend.cpp
URL: http://llvm.org/viewvc/llvm-project/llvm-gcc-4.2/trunk/gcc/llvm-backend.cpp?rev=83877&r1=83876&r2=83877&view=diff
==============================================================================
--- llvm-gcc-4.2/trunk/gcc/llvm-backend.cpp (original)
+++ llvm-gcc-4.2/trunk/gcc/llvm-backend.cpp Mon Oct 12 14:36:16 2009
@@ -396,7 +396,7 @@
Args.push_back("--disable-fp-elim");
if (!flag_zero_initialized_in_bss)
Args.push_back("--nozero-initialized-in-bss");
- if (flag_debug_asm)
+ if (flag_verbose_asm)
Args.push_back("--asm-verbose");
if (flag_debug_pass_structure)
Args.push_back("--debug-pass=Structure");
From baldrick at free.fr Mon Oct 12 14:37:58 2009
From: baldrick at free.fr (Duncan Sands)
Date: Mon, 12 Oct 2009 19:37:58 -0000
Subject: [llvm-commits] [llvm-gcc-4.2] r83878 - in /llvm-gcc-4.2/trunk/gcc:
config/i386/llvm-i386.cpp llvm-abi.h llvm-backend.cpp llvm-convert.cpp
llvm-types.cpp
Message-ID: <200910121937.n9CJbwAs021751@zion.cs.uiuc.edu>
Author: baldrick
Date: Mon Oct 12 14:37:58 2009
New Revision: 83878
URL: http://llvm.org/viewvc/llvm-project?rev=83878&view=rev
Log:
Port of dragonegg commit 83301: Use new predicates to test whether
a type is void, float etc.
Modified:
llvm-gcc-4.2/trunk/gcc/config/i386/llvm-i386.cpp
llvm-gcc-4.2/trunk/gcc/llvm-abi.h
llvm-gcc-4.2/trunk/gcc/llvm-backend.cpp
llvm-gcc-4.2/trunk/gcc/llvm-convert.cpp
llvm-gcc-4.2/trunk/gcc/llvm-types.cpp
Modified: llvm-gcc-4.2/trunk/gcc/config/i386/llvm-i386.cpp
URL: http://llvm.org/viewvc/llvm-project/llvm-gcc-4.2/trunk/gcc/config/i386/llvm-i386.cpp?rev=83878&r1=83877&r2=83878&view=diff
==============================================================================
--- llvm-gcc-4.2/trunk/gcc/config/i386/llvm-i386.cpp (original)
+++ llvm-gcc-4.2/trunk/gcc/config/i386/llvm-i386.cpp Mon Oct 12 14:37:58 2009
@@ -672,8 +672,8 @@
// as loads and stores of it get only 10 bytes.
if (EltTy == Type::getInt32Ty(Context) ||
EltTy == Type::getInt64Ty(Context) ||
- EltTy == Type::getFloatTy(Context) ||
- EltTy == Type::getDoubleTy(Context) ||
+ EltTy->isFloatTy() ||
+ EltTy->isDoubleTy() ||
isa(EltTy)) {
Elts.push_back(EltTy);
continue;
@@ -702,8 +702,8 @@
// short in 32-bit.
const Type *EltTy = STy->getElementType(0);
return !((TARGET_64BIT && (EltTy->isInteger() ||
- EltTy == Type::getFloatTy(Context) ||
- EltTy == Type::getDoubleTy(Context))) ||
+ EltTy->isFloatTy() ||
+ EltTy->isDoubleTy())) ||
EltTy == Type::getInt16Ty(Context) ||
EltTy == Type::getInt8Ty(Context));
}
@@ -746,7 +746,7 @@
++NumXMMs;
} else if (Ty->isInteger() || isa(Ty)) {
++NumGPRs;
- } else if (Ty==Type::getVoidTy(Context)) {
+ } else if (Ty->isVoidTy()) {
// Padding bytes that are not passed anywhere
;
} else {
Modified: llvm-gcc-4.2/trunk/gcc/llvm-abi.h
URL: http://llvm.org/viewvc/llvm-project/llvm-gcc-4.2/trunk/gcc/llvm-abi.h?rev=83878&r1=83877&r2=83878&view=diff
==============================================================================
--- llvm-gcc-4.2/trunk/gcc/llvm-abi.h (original)
+++ llvm-gcc-4.2/trunk/gcc/llvm-abi.h Mon Oct 12 14:37:58 2009
@@ -393,7 +393,7 @@
C.HandleScalarShadowResult(Ty->getPointerTo(), false);
else
C.HandleScalarResult(Ty);
- } else if (Ty->isSingleValueType() || Ty == Type::getVoidTy(getGlobalContext())) {
+ } else if (Ty->isSingleValueType() || Ty->isVoidTy()) {
// Return scalar values normally.
C.HandleScalarResult(Ty);
} else if (doNotUseShadowReturn(type, fn)) {
@@ -439,7 +439,7 @@
// Figure out if this field is zero bits wide, e.g. {} or [0 x int]. Do
// not include variable sized fields here.
std::vector Elts;
- if (Ty == Type::getVoidTy(getGlobalContext())) {
+ if (Ty->isVoidTy()) {
// Handle void explicitly as an opaque type.
const Type *OpTy = OpaqueType::get(getGlobalContext());
C.HandleScalarArgument(OpTy, type);
@@ -667,7 +667,7 @@
const Type* wordType = getTargetData().getPointerSize() == 4 ?
Type::getInt32Ty(getGlobalContext()) : Type::getInt64Ty(getGlobalContext());
for (unsigned i=0, e=Elts.size(); i!=e; ++i)
- if (OrigElts[i]==Type::getVoidTy(getGlobalContext()))
+ if (OrigElts[i]->isVoidTy())
Elts[i] = wordType;
const StructType *STy = StructType::get(getGlobalContext(), Elts, false);
@@ -749,7 +749,7 @@
C.HandleScalarShadowResult(Ty->getPointerTo(), false);
else
C.HandleScalarResult(Ty);
- } else if (Ty->isSingleValueType() || Ty == Type::getVoidTy(getGlobalContext())) {
+ } else if (Ty->isSingleValueType() || Ty->isVoidTy()) {
// Return scalar values normally.
C.HandleScalarResult(Ty);
} else if (doNotUseShadowReturn(type, fn)) {
@@ -1112,7 +1112,7 @@
const Type* wordType = getTargetData().getPointerSize() == 4
? Type::getInt32Ty(getGlobalContext()) : Type::getInt64Ty(getGlobalContext());
for (unsigned i=0, e=Elts.size(); i!=e; ++i)
- if (OrigElts[i]==Type::getVoidTy(getGlobalContext()))
+ if (OrigElts[i]->isVoidTy())
Elts[i] = wordType;
const StructType *STy = StructType::get(getGlobalContext(), Elts, false);
Modified: llvm-gcc-4.2/trunk/gcc/llvm-backend.cpp
URL: http://llvm.org/viewvc/llvm-project/llvm-gcc-4.2/trunk/gcc/llvm-backend.cpp?rev=83878&r1=83877&r2=83878&view=diff
==============================================================================
--- llvm-gcc-4.2/trunk/gcc/llvm-backend.cpp (original)
+++ llvm-gcc-4.2/trunk/gcc/llvm-backend.cpp Mon Oct 12 14:37:58 2009
@@ -1622,7 +1622,7 @@
// If we have "extern void foo", make the global have type {} instead of
// type void.
- if (Ty == Type::getVoidTy(Context))
+ if (Ty->isVoidTy())
Ty = StructType::get(Context);
if (Name[0] == 0) { // Global has no name.
Modified: llvm-gcc-4.2/trunk/gcc/llvm-convert.cpp
URL: http://llvm.org/viewvc/llvm-project/llvm-gcc-4.2/trunk/gcc/llvm-convert.cpp?rev=83878&r1=83877&r2=83878&view=diff
==============================================================================
--- llvm-gcc-4.2/trunk/gcc/llvm-convert.cpp (original)
+++ llvm-gcc-4.2/trunk/gcc/llvm-convert.cpp Mon Oct 12 14:37:58 2009
@@ -329,7 +329,7 @@
// If this is GCC being sloppy about pointer types, insert a bitcast.
// See PR1083 for an example.
ArgVal = Builder.CreateBitCast(ArgVal, LLVMTy);
- } else if (ArgVal->getType() == Type::getDoubleTy(Context)) {
+ } else if (ArgVal->getType()->isDoubleTy()) {
// If this is a K&R float parameter, it got promoted to double. Insert
// the truncation to float now.
ArgVal = Builder.CreateFPTrunc(ArgVal, LLVMTy,
@@ -2811,7 +2811,7 @@
if (Client.isShadowReturn())
return Client.EmitShadowResult(TREE_TYPE(exp), DestLoc);
- if (Call->getType() == Type::getVoidTy(Context))
+ if (Call->getType()->isVoidTy())
return 0;
if (Client.isAggrReturn()) {
@@ -3072,7 +3072,7 @@
assert(!isAggregateTreeType(TREE_TYPE(Op))
&& "Aggregate to scalar nop_expr!");
Value *OpVal = Emit(Op, DestLoc);
- if (Ty == Type::getVoidTy(Context)) return 0;
+ if (Ty->isVoidTy()) return 0;
return CastToAnyType(OpVal, OpIsSigned, Ty, ExpIsSigned);
} else if (isAggregateTreeType(TREE_TYPE(Op))) {
// Aggregate to aggregate copy.
@@ -6827,7 +6827,7 @@
const Type *Ty = ConvertType(TREE_TYPE(exp));
// If we have "extern void foo", make the global have type {} instead of
// type void.
- if (Ty == Type::getVoidTy(Context)) Ty = StructType::get(Context);
+ if (Ty->isVoidTy()) Ty = StructType::get(Context);
const PointerType *PTy = Ty->getPointerTo();
unsigned Alignment = Ty->isSized() ? TD.getABITypeAlignment(Ty) : 1;
if (DECL_ALIGN(exp)) {
@@ -7046,7 +7046,7 @@
int UArr[2];
double V;
};
- if (Ty==Type::getFloatTy(Context) || Ty==Type::getDoubleTy(Context)) {
+ if (Ty->isFloatTy() || Ty->isDoubleTy()) {
REAL_VALUE_TO_TARGET_DOUBLE(TREE_REAL_CST(exp), RealArr);
// Here's how this works:
@@ -7072,9 +7072,9 @@
std::swap(UArr[0], UArr[1]);
return
- ConstantFP::get(Context, Ty==Type::getFloatTy(Context) ?
+ ConstantFP::get(Context, Ty->isFloatTy() ?
APFloat((float)V) : APFloat(V));
- } else if (Ty==Type::getX86_FP80Ty(Context)) {
+ } else if (Ty->isX86_FP80Ty()) {
long RealArr[4];
uint64_t UArr[2];
REAL_VALUE_TO_TARGET_LONG_DOUBLE(TREE_REAL_CST(exp), RealArr);
@@ -7082,8 +7082,8 @@
((uint64_t)((uint32_t)RealArr[1]) << 32);
UArr[1] = (uint16_t)RealArr[2];
return ConstantFP::get(Context, APFloat(APInt(80, 2, UArr)));
- } else if (Ty==Type::getPPC_FP128Ty(Context) ||
- Ty==Type::getFP128Ty(Context)) {
+ } else if (Ty->isPPC_FP128Ty() ||
+ Ty->isFP128Ty()) {
long RealArr[4];
uint64_t UArr[2];
REAL_VALUE_TO_TARGET_LONG_DOUBLE(TREE_REAL_CST(exp), RealArr);
@@ -7094,7 +7094,7 @@
((uint64_t)((uint32_t)RealArr[3]));
return ConstantFP::get(Context,
APFloat(APInt(128, 2, UArr),
- /*isIEEE*/ Ty==Type::getFP128Ty(Context)));
+ /*isIEEE*/ Ty->isFP128Ty()));
}
assert(0 && "Floating point type not handled yet");
return 0; // outwit compiler warning
@@ -7960,7 +7960,7 @@
// itself (allowed in GCC but not in LLVM) then the global is changed to have
// the type of the initializer. Correct for this now.
const Type *Ty = ConvertType(TREE_TYPE(exp));
- if (Ty == Type::getVoidTy(Context)) Ty = Type::getInt8Ty(Context); // void* -> i8*.
+ if (Ty->isVoidTy()) Ty = Type::getInt8Ty(Context); // void* -> i8*.
return TheFolder->CreateBitCast(Val, Ty->getPointerTo());
}
Modified: llvm-gcc-4.2/trunk/gcc/llvm-types.cpp
URL: http://llvm.org/viewvc/llvm-project/llvm-gcc-4.2/trunk/gcc/llvm-types.cpp?rev=83878&r1=83877&r2=83878&view=diff
==============================================================================
--- llvm-gcc-4.2/trunk/gcc/llvm-types.cpp (original)
+++ llvm-gcc-4.2/trunk/gcc/llvm-types.cpp Mon Oct 12 14:37:58 2009
@@ -804,7 +804,7 @@
// Restore ConvertingStruct for the caller.
ConvertingStruct = false;
- if (Actual == Type::getVoidTy(Context))
+ if (Actual->isVoidTy())
Actual = Type::getInt8Ty(Context); // void* -> sbyte*
// Update the type, potentially updating TYPE_LLVM(type).
@@ -838,7 +838,7 @@
Ty = ConvertType(TREE_TYPE(type));
}
- if (Ty == Type::getVoidTy(Context))
+ if (Ty->isVoidTy())
Ty = Type::getInt8Ty(Context); // void* -> sbyte*
return TypeDB.setType(type, Ty->getPointerTo());
}
From clattner at apple.com Mon Oct 12 14:40:07 2009
From: clattner at apple.com (Chris Lattner)
Date: Mon, 12 Oct 2009 12:40:07 -0700
Subject: [llvm-commits] patch: memory use markers
In-Reply-To:
References: <4AD25B50.4000008@mxc.ca>
<19D8DF80-620E-41D0-915D-A3D505766B00@apple.com>
Message-ID:
On Oct 12, 2009, at 11:44 AM, Nick Lewycky wrote:
> 2009/10/12 Dan Gohman
>
> On Oct 11, 2009, at 3:25 PM, Nick Lewycky wrote:
>
> > This patch adds memory use markers as described in http://nondot.org/sabre/LLVMNotes/MemoryUseMarkers.txt
> > . The bulk of the patch makes it possible to have intrinsics which
> > return {}.
>
> Hi Nick,
>
> The use of {} here is clever, but I don't think it's correct. Since {}
> has
> no members, the set of values has exactly one element, which means
> that all values of type {} can be assumed to be equivalent. Please use
> something like opaque* instead.
>
> I brought that up with Chris much earlier on (since I would've had
> this patch done a month ago were it not for the need to support {})
> but he was adamant that {} was the correct type for these. I was
> suggesting metadata type though; opaque types require a name in the
> module.
Dan convinced me that {} was a bad way to go, lets use "{}*" instead,
does that work for you?
-Chris
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/llvm-commits/attachments/20091012/b9e2c293/attachment.html
From baldrick at free.fr Mon Oct 12 14:40:31 2009
From: baldrick at free.fr (Duncan Sands)
Date: Mon, 12 Oct 2009 19:40:31 -0000
Subject: [llvm-commits] [llvm-gcc-4.2] r83879 -
/llvm-gcc-4.2/trunk/gcc/llvm-convert.cpp
Message-ID: <200910121940.n9CJeV6t021901@zion.cs.uiuc.edu>
Author: baldrick
Date: Mon Oct 12 14:40:30 2009
New Revision: 83879
URL: http://llvm.org/viewvc/llvm-project?rev=83879&view=rev
Log:
Port of dragonegg commit 82041: Remove an incorrect assertion. This fires
when adding (for example) an i1 field. Adding an i1 field does not mean
adding a bitfield, it means adding a byte of which only the first bit is used.
Since all the logic uses the AllocSize, which is 1 byte for an i1, as far as
I can see everything should work correctly in this case.
Modified:
llvm-gcc-4.2/trunk/gcc/llvm-convert.cpp
Modified: llvm-gcc-4.2/trunk/gcc/llvm-convert.cpp
URL: http://llvm.org/viewvc/llvm-project/llvm-gcc-4.2/trunk/gcc/llvm-convert.cpp?rev=83879&r1=83878&r2=83879&view=diff
==============================================================================
--- llvm-gcc-4.2/trunk/gcc/llvm-convert.cpp (original)
+++ llvm-gcc-4.2/trunk/gcc/llvm-convert.cpp Mon Oct 12 14:40:30 2009
@@ -7473,9 +7473,6 @@
///
void ConstantLayoutInfo::
AddFieldToRecordConstant(Constant *Val, uint64_t GCCFieldOffsetInBits) {
- assert((TD.getTypeSizeInBits(Val->getType()) & 7) == 0 &&
- "Cannot handle non-byte sized values");
-
// Figure out how to add this non-bitfield value to our constant struct so
// that it ends up at the right offset. There are four cases we have to
// think about:
From clattner at apple.com Mon Oct 12 14:41:28 2009
From: clattner at apple.com (Chris Lattner)
Date: Mon, 12 Oct 2009 12:41:28 -0700
Subject: [llvm-commits] patch: memory use markers
In-Reply-To:
References: <4AD25B50.4000008@mxc.ca>
<19D8DF80-620E-41D0-915D-A3D505766B00@apple.com>
Message-ID:
On Oct 12, 2009, at 11:44 AM, Nick Lewycky wrote:
> 2009/10/12 Dan Gohman
>
> With @llvm.invariant.end being marked readonly and nounwind, and
> having
> a void return type, it would seem to be trivially dead everywhere.
> Should
> the readonly be removed?
>
> Good catch! Does this rule apply to intrinsics as well? How does
> @llvm.gcread work?
gcread should be deleted when dead. Basicaa should special case these
new intrinsics to say that they always have an empty mod/ref set.
-Chris
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/llvm-commits/attachments/20091012/c6ff592d/attachment.html
From bob.wilson at apple.com Mon Oct 12 15:37:23 2009
From: bob.wilson at apple.com (Bob Wilson)
Date: Mon, 12 Oct 2009 20:37:23 -0000
Subject: [llvm-commits] [llvm] r83894 -
/llvm/trunk/lib/Target/ARM/ARMConstantIslandPass.cpp
Message-ID: <200910122037.n9CKbOuQ024747@zion.cs.uiuc.edu>
Author: bwilson
Date: Mon Oct 12 15:37:23 2009
New Revision: 83894
URL: http://llvm.org/viewvc/llvm-project?rev=83894&view=rev
Log:
Remove redundant parameter.
Modified:
llvm/trunk/lib/Target/ARM/ARMConstantIslandPass.cpp
Modified: llvm/trunk/lib/Target/ARM/ARMConstantIslandPass.cpp
URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/lib/Target/ARM/ARMConstantIslandPass.cpp?rev=83894&r1=83893&r2=83894&view=diff
==============================================================================
--- llvm/trunk/lib/Target/ARM/ARMConstantIslandPass.cpp (original)
+++ llvm/trunk/lib/Target/ARM/ARMConstantIslandPass.cpp Mon Oct 12 15:37:23 2009
@@ -165,8 +165,7 @@
int LookForExistingCPEntry(CPUser& U, unsigned UserOffset);
bool LookForWater(CPUser&U, unsigned UserOffset,
MachineBasicBlock *&NewMBB);
- MachineBasicBlock* AcceptWater(MachineBasicBlock *WaterBB,
- water_iterator IP);
+ MachineBasicBlock *AcceptWater(water_iterator IP);
void CreateNewWater(unsigned CPUserIndex, unsigned UserOffset,
MachineBasicBlock** NewMBB);
bool HandleConstantPoolUser(MachineFunction &MF, unsigned CPUserIndex);
@@ -932,9 +931,8 @@
}
/// AcceptWater - Small amount of common code factored out of the following.
-
-MachineBasicBlock* ARMConstantIslands::AcceptWater(MachineBasicBlock *WaterBB,
- water_iterator IP) {
+///
+MachineBasicBlock *ARMConstantIslands::AcceptWater(water_iterator IP) {
DEBUG(errs() << "found water in range\n");
// Remove the original WaterList entry; we want subsequent
// insertions in this vicinity to go after the one we're
@@ -942,7 +940,7 @@
// of times we have to move the same CPE more than once.
WaterList.erase(IP);
// CPE goes before following block (NewMBB).
- return next(MachineFunction::iterator(WaterBB));
+ return next(MachineFunction::iterator(*IP));
}
/// LookForWater - look for an existing entry in the WaterList in which
@@ -973,7 +971,7 @@
IPThatWouldPad = IP;
}
} else {
- NewMBB = AcceptWater(WaterBB, IP);
+ NewMBB = AcceptWater(IP);
return true;
}
}
@@ -981,7 +979,7 @@
break;
}
if (isThumb && WaterBBThatWouldPad) {
- NewMBB = AcceptWater(WaterBBThatWouldPad, IPThatWouldPad);
+ NewMBB = AcceptWater(IPThatWouldPad);
return true;
}
return false;
From sabre at nondot.org Mon Oct 12 15:42:36 2009
From: sabre at nondot.org (Chris Lattner)
Date: Mon, 12 Oct 2009 20:42:36 -0000
Subject: [llvm-commits] [llvm] r83895 -
/llvm/trunk/test/FrontendC/2008-03-24-BitField-And-Alloca.c
Message-ID: <200910122042.n9CKgarv025039@zion.cs.uiuc.edu>
Author: lattner
Date: Mon Oct 12 15:42:35 2009
New Revision: 83895
URL: http://llvm.org/viewvc/llvm-project?rev=83895&view=rev
Log:
allow this testcase to pass with recent changes. The test hasn't been
producing any stores at all for a long time, but ".store." was in some
IR instruction names until recently. This removal caused the test to
start failing. Just make it reject any stores.
Modified:
llvm/trunk/test/FrontendC/2008-03-24-BitField-And-Alloca.c
Modified: llvm/trunk/test/FrontendC/2008-03-24-BitField-And-Alloca.c
URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/test/FrontendC/2008-03-24-BitField-And-Alloca.c?rev=83895&r1=83894&r2=83895&view=diff
==============================================================================
--- llvm/trunk/test/FrontendC/2008-03-24-BitField-And-Alloca.c (original)
+++ llvm/trunk/test/FrontendC/2008-03-24-BitField-And-Alloca.c Mon Oct 12 15:42:35 2009
@@ -1,5 +1,5 @@
// RUN: %llvmgcc -O2 -S %s -o - | not grep alloca
-// RUN: %llvmgcc -m32 -O2 -S %s -o - | grep store | not grep {align 8}
+// RUN: %llvmgcc -m32 -O2 -S %s -o - | not grep store
enum {
PP_C,
From bob.wilson at apple.com Mon Oct 12 15:45:53 2009
From: bob.wilson at apple.com (Bob Wilson)
Date: Mon, 12 Oct 2009 20:45:53 -0000
Subject: [llvm-commits] [llvm] r83897 -
/llvm/trunk/lib/Target/ARM/ARMConstantIslandPass.cpp
Message-ID: <200910122045.n9CKjrcw025232@zion.cs.uiuc.edu>
Author: bwilson
Date: Mon Oct 12 15:45:53 2009
New Revision: 83897
URL: http://llvm.org/viewvc/llvm-project?rev=83897&view=rev
Log:
Another minor clean-up.
Modified:
llvm/trunk/lib/Target/ARM/ARMConstantIslandPass.cpp
Modified: llvm/trunk/lib/Target/ARM/ARMConstantIslandPass.cpp
URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/lib/Target/ARM/ARMConstantIslandPass.cpp?rev=83897&r1=83896&r2=83897&view=diff
==============================================================================
--- llvm/trunk/lib/Target/ARM/ARMConstantIslandPass.cpp (original)
+++ llvm/trunk/lib/Target/ARM/ARMConstantIslandPass.cpp Mon Oct 12 15:45:53 2009
@@ -952,11 +952,11 @@
/// group, prefer the water that's farthest away.
bool ARMConstantIslands::LookForWater(CPUser &U, unsigned UserOffset,
MachineBasicBlock *&NewMBB) {
- water_iterator IPThatWouldPad;
- MachineBasicBlock* WaterBBThatWouldPad = NULL;
if (WaterList.empty())
return false;
+ bool FoundWaterThatWouldPad = false;
+ water_iterator IPThatWouldPad;
for (water_iterator IP = prior(WaterList.end()),
B = WaterList.begin();; --IP) {
MachineBasicBlock* WaterBB = *IP;
@@ -966,8 +966,8 @@
(BBOffsets[WBBId] + BBSizes[WBBId])%4 != 0) {
// This is valid Water, but would introduce padding. Remember
// it in case we don't find any Water that doesn't do this.
- if (!WaterBBThatWouldPad) {
- WaterBBThatWouldPad = WaterBB;
+ if (!FoundWaterThatWouldPad) {
+ FoundWaterThatWouldPad = true;
IPThatWouldPad = IP;
}
} else {
@@ -978,7 +978,7 @@
if (IP == B)
break;
}
- if (isThumb && WaterBBThatWouldPad) {
+ if (FoundWaterThatWouldPad) {
NewMBB = AcceptWater(IPThatWouldPad);
return true;
}
From bob.wilson at apple.com Mon Oct 12 16:23:15 2009
From: bob.wilson at apple.com (Bob Wilson)
Date: Mon, 12 Oct 2009 21:23:15 -0000
Subject: [llvm-commits] [llvm] r83902 -
/llvm/trunk/lib/Target/ARM/ARMConstantIslandPass.cpp
Message-ID: <200910122123.n9CLNGLs026827@zion.cs.uiuc.edu>
Author: bwilson
Date: Mon Oct 12 16:23:15 2009
New Revision: 83902
URL: http://llvm.org/viewvc/llvm-project?rev=83902&view=rev
Log:
Last week, ARMConstantIslandPass was failing to converge for the
MultiSource/Benchmarks/MiBench/automotive-susan test. The failure has
since been masked by an unrelated change (just randomly), so I don't have
a testcase for this now. Radar 7291928.
The situation where this happened is that a constant pool entry (CPE) was
placed at a lower address than the load that referenced it. There were in
fact 2 CPEs placed at adjacent addresses and referenced by 2 loads that were
close together in the code. The distance from the loads to the CPEs was
right at the limit of what they could handle, so that only one of the CPEs
could be placed within range. On every iteration, the first CPE was found
to be out of range, causing a new CPE to be inserted. The second CPE had
been in range but the newly inserted entry pushed it too far away. Thus the
second CPE was also replaced by a new entry, which in turn pushed the first
CPE out of range. Etc.
Judging from some comments in the code, the initial implementation of this
pass did not support CPEs placed _before_ their references. In the case
where the CPE is placed at a higher address, the key to making the algorithm
terminate is that new CPEs are only inserted at the end of a group of adjacent
CPEs. This is implemented by removing a basic block from the "WaterList"
once it has been used, and then adding the newly inserted CPE block to the
list so that the next insertion will come after it. This avoids the ping-pong
effect where CPEs are repeatedly moved to the beginning of a group of
adjacent CPEs. This does not work when going backwards, however, because the
entries at the end of an adjacent group of CPEs are closer than the CPEs
earlier in the group.
To make this pass terminate, we need to maintain a property that changes can
only happen in some sort of monotonic fashion. The fix used here is to require
that the CPE for a particular constant pool load can only move to lower
addresses. This is a very simple change to the code and should not cause
any significant degradation in the results.
Modified:
llvm/trunk/lib/Target/ARM/ARMConstantIslandPass.cpp
Modified: llvm/trunk/lib/Target/ARM/ARMConstantIslandPass.cpp
URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/lib/Target/ARM/ARMConstantIslandPass.cpp?rev=83902&r1=83901&r2=83902&view=diff
==============================================================================
--- llvm/trunk/lib/Target/ARM/ARMConstantIslandPass.cpp (original)
+++ llvm/trunk/lib/Target/ARM/ARMConstantIslandPass.cpp Mon Oct 12 16:23:15 2009
@@ -946,10 +946,11 @@
/// LookForWater - look for an existing entry in the WaterList in which
/// we can place the CPE referenced from U so it's within range of U's MI.
/// Returns true if found, false if not. If it returns true, NewMBB
-/// is set to the WaterList entry.
-/// For ARM, we prefer the water that's farthest away. For Thumb, prefer
-/// water that will not introduce padding to water that will; within each
-/// group, prefer the water that's farthest away.
+/// is set to the WaterList entry. For Thumb, prefer water that will not
+/// introduce padding to water that will. To ensure that this pass
+/// terminates, the CPE location for a particular CPUser is only allowed to
+/// move to a lower address, so search backward from the end of the list and
+/// prefer the first water that is in range.
bool ARMConstantIslands::LookForWater(CPUser &U, unsigned UserOffset,
MachineBasicBlock *&NewMBB) {
if (WaterList.empty())
@@ -960,7 +961,9 @@
for (water_iterator IP = prior(WaterList.end()),
B = WaterList.begin();; --IP) {
MachineBasicBlock* WaterBB = *IP;
- if (WaterIsInRange(UserOffset, WaterBB, U)) {
+ // Check if water is in range and at a lower address than the current one.
+ if (WaterIsInRange(UserOffset, WaterBB, U) &&
+ WaterBB->getNumber() < U.CPEMI->getParent()->getNumber()) {
unsigned WBBId = WaterBB->getNumber();
if (isThumb &&
(BBOffsets[WBBId] + BBSizes[WBBId])%4 != 0) {
@@ -1109,10 +1112,7 @@
// We will be generating a new clone. Get a UID for it.
unsigned ID = AFI->createConstPoolEntryUId();
- // Look for water where we can place this CPE. We look for the farthest one
- // away that will work. Forward references only for now (although later
- // we might find some that are backwards).
-
+ // Look for water where we can place this CPE.
if (!LookForWater(U, UserOffset, NewMBB)) {
// No water found.
DEBUG(errs() << "No water found\n");
From bob.wilson at apple.com Mon Oct 12 16:39:43 2009
From: bob.wilson at apple.com (Bob Wilson)
Date: Mon, 12 Oct 2009 21:39:43 -0000
Subject: [llvm-commits] [llvm] r83905 -
/llvm/trunk/lib/Target/ARM/ARMConstantIslandPass.cpp
Message-ID: <200910122139.n9CLdikP027662@zion.cs.uiuc.edu>
Author: bwilson
Date: Mon Oct 12 16:39:43 2009
New Revision: 83905
URL: http://llvm.org/viewvc/llvm-project?rev=83905&view=rev
Log:
Change CreateNewWater method to return NewMBB by reference.
Modified:
llvm/trunk/lib/Target/ARM/ARMConstantIslandPass.cpp
Modified: llvm/trunk/lib/Target/ARM/ARMConstantIslandPass.cpp
URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/lib/Target/ARM/ARMConstantIslandPass.cpp?rev=83905&r1=83904&r2=83905&view=diff
==============================================================================
--- llvm/trunk/lib/Target/ARM/ARMConstantIslandPass.cpp (original)
+++ llvm/trunk/lib/Target/ARM/ARMConstantIslandPass.cpp Mon Oct 12 16:39:43 2009
@@ -167,7 +167,7 @@
MachineBasicBlock *&NewMBB);
MachineBasicBlock *AcceptWater(water_iterator IP);
void CreateNewWater(unsigned CPUserIndex, unsigned UserOffset,
- MachineBasicBlock** NewMBB);
+ MachineBasicBlock *&NewMBB);
bool HandleConstantPoolUser(MachineFunction &MF, unsigned CPUserIndex);
void RemoveDeadCPEMI(MachineInstr *CPEMI);
bool RemoveUnusedCPEntries();
@@ -992,12 +992,12 @@
/// CPUsers[CPUserIndex], so create a place to put the CPE. The end of the
/// block is used if in range, and the conditional branch munged so control
/// flow is correct. Otherwise the block is split to create a hole with an
-/// unconditional branch around it. In either case *NewMBB is set to a
+/// unconditional branch around it. In either case NewMBB is set to a
/// block following which the new island can be inserted (the WaterList
/// is not adjusted).
-
void ARMConstantIslands::CreateNewWater(unsigned CPUserIndex,
- unsigned UserOffset, MachineBasicBlock** NewMBB) {
+ unsigned UserOffset,
+ MachineBasicBlock *&NewMBB) {
CPUser &U = CPUsers[CPUserIndex];
MachineInstr *UserMI = U.MI;
MachineInstr *CPEMI = U.CPEMI;
@@ -1019,7 +1019,7 @@
DEBUG(errs() << "Split at end of block\n");
if (&UserMBB->back() == UserMI)
assert(BBHasFallthrough(UserMBB) && "Expected a fallthrough BB!");
- *NewMBB = next(MachineFunction::iterator(UserMBB));
+ NewMBB = next(MachineFunction::iterator(UserMBB));
// Add an unconditional branch from UserMBB to fallthrough block.
// Record it for branch lengthening; this new branch will not get out of
// range, but if the preceding conditional branch is out of range, the
@@ -1027,7 +1027,7 @@
// range, so the machinery has to know about it.
int UncondBr = isThumb ? ((isThumb2) ? ARM::t2B : ARM::tB) : ARM::B;
BuildMI(UserMBB, DebugLoc::getUnknownLoc(),
- TII->get(UncondBr)).addMBB(*NewMBB);
+ TII->get(UncondBr)).addMBB(NewMBB);
unsigned MaxDisp = getUnconditionalBrDisp(UncondBr);
ImmBranches.push_back(ImmBranch(&UserMBB->back(),
MaxDisp, false, UncondBr));
@@ -1082,7 +1082,7 @@
}
}
DEBUG(errs() << "Split in middle of big block\n");
- *NewMBB = SplitBlockBeforeInstr(prior(MI));
+ NewMBB = SplitBlockBeforeInstr(prior(MI));
}
}
@@ -1116,7 +1116,7 @@
if (!LookForWater(U, UserOffset, NewMBB)) {
// No water found.
DEBUG(errs() << "No water found\n");
- CreateNewWater(CPUserIndex, UserOffset, &NewMBB);
+ CreateNewWater(CPUserIndex, UserOffset, NewMBB);
}
// Okay, we know we can put an island before NewMBB now, do it!
From tonic at nondot.org Mon Oct 12 16:53:27 2009
From: tonic at nondot.org (Tanya Lattner)
Date: Mon, 12 Oct 2009 16:53:27 -0500
Subject: [llvm-commits] CVS:
llvm-www/devmtg/2009-10/Cifuentes_ParfaitBugChecker.pdf
Geoffray_GarbageCollectionVMKit.pdf Grover_PLANG.pdf
Korobeynikov_BackendTutorial.pdf Nagarakatte_SoftBound.pdf
Osborne_TargetingXCoreResources.pdf Sands_LLVMGCCPlugin.pdf
Winter_UnladenSwallowLLVM.pdf Zaks_CoVaC.pdf index.html
Message-ID: <200910122153.n9CLrRaO028279@zion.cs.uiuc.edu>
Changes in directory llvm-www/devmtg/2009-10:
Cifuentes_ParfaitBugChecker.pdf added (r1.1)
Geoffray_GarbageCollectionVMKit.pdf added (r1.1)
Grover_PLANG.pdf added (r1.1)
Korobeynikov_BackendTutorial.pdf added (r1.1)
Nagarakatte_SoftBound.pdf added (r1.1)
Osborne_TargetingXCoreResources.pdf added (r1.1)
Sands_LLVMGCCPlugin.pdf added (r1.1)
Winter_UnladenSwallowLLVM.pdf added (r1.1)
Zaks_CoVaC.pdf added (r1.1)
index.html updated: 1.1 -> 1.2
---
Log message:
Starting to add slides to the website.
---
Diffs of the changes: (+254 -5)
Cifuentes_ParfaitBugChecker.pdf | 0
Geoffray_GarbageCollectionVMKit.pdf | 0
Grover_PLANG.pdf | 0
Korobeynikov_BackendTutorial.pdf | 0
Nagarakatte_SoftBound.pdf | 0
Osborne_TargetingXCoreResources.pdf | 0
Sands_LLVMGCCPlugin.pdf | 0
Winter_UnladenSwallowLLVM.pdf | 0
Zaks_CoVaC.pdf | 0
index.html | 259 +++++++++++++++++++++++++++++++++++-
10 files changed, 254 insertions(+), 5 deletions(-)
Index: llvm-www/devmtg/2009-10/Cifuentes_ParfaitBugChecker.pdf
Index: llvm-www/devmtg/2009-10/Geoffray_GarbageCollectionVMKit.pdf
Index: llvm-www/devmtg/2009-10/Grover_PLANG.pdf
Index: llvm-www/devmtg/2009-10/Korobeynikov_BackendTutorial.pdf
Index: llvm-www/devmtg/2009-10/Nagarakatte_SoftBound.pdf
Index: llvm-www/devmtg/2009-10/Osborne_TargetingXCoreResources.pdf
Index: llvm-www/devmtg/2009-10/Sands_LLVMGCCPlugin.pdf
Index: llvm-www/devmtg/2009-10/Winter_UnladenSwallowLLVM.pdf
Index: llvm-www/devmtg/2009-10/Zaks_CoVaC.pdf
Index: llvm-www/devmtg/2009-10/index.html
diff -u llvm-www/devmtg/2009-10/index.html:1.1 llvm-www/devmtg/2009-10/index.html:1.2
--- llvm-www/devmtg/2009-10/index.html:1.1 Thu Jul 9 13:48:42 2009
+++ llvm-www/devmtg/2009-10/index.html Mon Oct 12 16:52:21 2009
@@ -1,5 +1,254 @@
-
-
-LLVM Developers' Meeting
-
-
+
+
+
The meeting serves as a forum for both LLVM
+and Clang developers and users to get acquainted, lea
+rn how LLVM is used, and
+exchange ideas about LLVM and its (potential) applications. More broadly, we
+believe the event will be of particular interest to the following people:
+
+
+
Active LLVM and Clang developers and users.
+
Anyone interested in using LLVM or Clang.
+
Compiler, programming language, and runtime enthusiasts.
+
Those interested in using compiler technology in novel and interesting ways.
+
+
+
+
Proceedings
+
+
The day was structured to have general overview/introduction talks about some
+major LLVM subsystems and talks on applications of LLVM for various
+specific projects.
Precise and efficient garbage collection in VMKit with MMTk -
+ This talk will describe how we have added precise garbage collection in VMKit, both in the JVM and .Net runtime. The work continues in the spirit of VMKit, in that the garbage collector is an external library provided by others. We have used MMTk, a garbage collector written in Java to provide efficient and precise garbage collection. The talk will give a step by step explanation on how the new system was implemented (using LLVM as an ahead of time compiler for Java, using the LLVM GC framework, creating stack maps at runtime, etc), and provide a tutorial on how this can be adopted by other kinds of VMs implemented with LLVM. Additionally, I will show the new performance results with the new garbage collector. The new system continues to support big applications (eclipse, tomcat, DaCapo benchmarks), and provides way better performance than before.
+
Unladen Swallow: Python on LLVM -
+ This talk will go into detail about Unladen Swallow, a Google-sponsored branch of CPython based on LLVM. The talk will describe the architecture of Python-on-LLVM, why we chose LLVM, how we're exploiting LLVM to increase performance, challenges we face in optimizing Python, and future direction for our work.
+
Reimplementing llvm-gcc as a gcc plugin -
+ Mainline gcc is now able to load additional logic and passes at run-time via a plugin mechanism. It may be possible to replace gcc's optimizers and code generators with those of LLVM via a plugin without needing to modify gcc at all. The goal is to obtain an equivalent of llvm-gcc in this way. I will describe the current status of this project.
+
+
+
+
+
+ [No Slides]
+ [No Video]
+
+
Dan Gohman
+
ScalarEvolution and Loop Optimization - LLVM's ScalarEvolution framework has undergone some major changes and now sports some cool new features. I'll give an overview of what ScalarEvolution can do, illustrate the new features, and discuss the infrastructure behind the functionality.
+
+
+
+
+
+
+
+
Bruno Cardoso Lopes University of Campinas
+
Object Code Emission and llvm-mc -
+ A high level overview of the LLVM Machine Code Emitter, with a specific focus on the emission of object files: the design and current implementation status.
+
+
+
+
+
+
+
+
David Greene Cray
+
LLVM on 180k Cores -
+ In this talk we'll see how Cray incorporated LLVM into an existing highly optimizing, vectorizing and parallelizing compiler. Attendees will learn about the pitfalls encountered as well as the benefits of using an Open Source codegen solution. We will also discuss various modifications to LLVM that Cray is currently in the process of integrating back into the community repository.
+
The Parfait Bug-Checker -
+ Parfait is a research bug-checking project for C built on top of LLVM. Parfait is being used internally within Sun to find bugs in various applications including the Solaris(TM) operating system. Externally, Parfait is being tested in the OS community with the OpenBSD, Linux and FreeBSD kernels. In this talk we explain Parfait's design for scalability and precision, explain some of the internals of the tool and how it is built on top of LLVM, and give a demo against open source code bases.
+
Optimizing ActionScript Bytecode using LLVM -
+ LLVM has state-of-the-art optimization capabilities that can operate against LLVM bitcode. But many of these optimizations are not intrinsically specific to LLVM's representation of programs. Adobe has built a proof-of-concept implementation of an ActionScript Bytecode optimizer using LLVM. This talk will discuss the implementation of the optimizer and possible future directions for this type of technology.
+
Targeting XCore resources from LLVM -
+ The XCore is an event driven multi-threaded processor. It provides direct hardware support for interprocess communication using channels and precise timing of inputs and outputs on I/O pins using ports. This talks looks at using LLVM to compile an version of C extended with support for explicit parallelism and I/O to the XCore.
+
+
+
+
+
+ [No Slides]
+ [No Videos]
+
+
Lang Hames
+
Future Works in LLVM Register Allocation - About the future of register allocation in LLVM.
+
CoVaC: Compiler Validation by Program Analysis of the Cross-Product - I
+ n this talk, I am going to present CoVaC, which is a framework for formal verification of the compiler optimization phase, and give a brief overview of the prototype tool, which has been developed on top of LLVM 2.0. The CoVaC framework checks that optimization passes preserve semantics of the program being compiled by proving that the unoptimized program is equivalent to the optimized one. To leverage existing program analysis techniques, we reduce the equivalence checking problem to analysis of one system - a cross-product of the two input programs. Unlike existing frameworks, CoVaC accommodates absence of compiler annotations and handles most of the classical intraprocedural optimizations such as constant folding, reassociation, common subexpression elimination, code motion, dead code elimination, branch optimizations, and others. The talk is based on the following paper: Compiler Validation by Program Analysis of the Cross-Product, Anna Zaks and Amir Pnueli, FM'08
+
ftBound: Highly Compatible and Complete Spatial Memory Safety for C -
+ The serious bugs and security vulnerabilities facilitated by C/C++???s lack of bounds checking are well known, yet C and C++ remain in widespread use. Unfortunately, C???s arbitrary pointer arithmetic, conflation of pointers and arrays, and programmer-visible memory layout make retrofitting C/C++ with spatial safety guarantees extremely challenging. Existing approaches suffer from incompleteness, have high runtime overhead, or require non-trivial changes to the C source code. Thus far, these deficiencies have prevented widespread adoption of such techniques. In this talk, I will present SoftBound, a compile-time transformation for enforcing spatial safety of C. SoftBound records base and bound information for every pointer as disjoint metadata. This decoupling enables SoftBound to provide spatial safety without requiring changes to C source code. SoftBound is a software-only approach and performs metadata manipulation only when loading or storing pointer values. I will !
also provide a brief description of the formal proof and llvm implementation. SoftBound???s full checking mode provides complete spatial violation detection with 67% runtime overhead on average. To further reduce overheads, SoftBound has a store-only checking mode that successfully detects all the security vulnerabilities in a test suite at the cost of only 22% runtime overhead on average.
+
PLANG: Translating NVIDIA PTX language to LLVM IR
+ Machine -
+ PTX is an abstract ISA, for NVIDIA GPUs, targeted by CUDA and several other tools. PTX is jitted or compiled to a supported GPU for execution. We describe PLANG, a new front-end for PTX that emits LLVM and leverages its analysis, transformation and code generation infrastructure for PTX. Based on PLANG we have built several analysis and translation tools for PTX, e.g. synchronization analysis, visualization and targeting execution of PTX on x86 processors. In this talk we will describe PLANG, and our experiences in building tools based on LLVM.
+
+
+
+
+
+
+
+
+
Accelerating Ruby with LLVM
+ -
+ Rubinius is a ruby VM that strives to write as much of the system in ruby itself as it can. To make this practical, we're using LLVM to JIT frequently used methods. I'll cover briefly the architecture of Rubinius, spending most of the time discussing the integration points. These include: Background compilation, runtime profile guide optimization, efficient IR generation, etc.
+
+
+
+
+
+
+
+ Last modified: $Date: 2009/10/12 21:52:21 $
+
+
+
From tbrethou at cs.uiuc.edu Mon Oct 12 16:53:35 2009
From: tbrethou at cs.uiuc.edu (Tanya Lattner)
Date: Mon, 12 Oct 2009 16:53:35 -0500
Subject: [llvm-commits] CVS: llvm-www/devmtg/2009-10/index.php
Message-ID: <200910122153.n9CLrZm0028305@zion.cs.uiuc.edu>
Changes in directory llvm-www/devmtg/2009-10:
index.php (r1.40) removed
---
Log message:
Remove old page and replace with static one.
---
Diffs of the changes: (+0 -0)
0 files changed
From dalej at apple.com Mon Oct 12 16:54:01 2009
From: dalej at apple.com (Dale Johannesen)
Date: Mon, 12 Oct 2009 14:54:01 -0700
Subject: [llvm-commits] [llvm] r83902 -
/llvm/trunk/lib/Target/ARM/ARMConstantIslandPass.cpp
In-Reply-To: <200910122123.n9CLNGLs026827@zion.cs.uiuc.edu>
References: <200910122123.n9CLNGLs026827@zion.cs.uiuc.edu>
Message-ID: <5435A54B-30DB-43F9-BBB4-81DA4DED3CCB@apple.com>
On Oct 12, 2009, at 2:23 PMPDT, Bob Wilson wrote:
> Author: bwilson
> Date: Mon Oct 12 16:23:15 2009
> New Revision: 83902
>
> URL: http://llvm.org/viewvc/llvm-project?rev=83902&view=rev
> Log:
> Last week, ARMConstantIslandPass was failing to converge for the
> MultiSource/Benchmarks/MiBench/automotive-susan test. The failure has
> since been masked by an unrelated change (just randomly), so I don't
> have
> a testcase for this now. Radar 7291928.
Thanks for tracking this down and fixing it. The last person to hit
it was not so brave; can we get rid of 78377 now?
From tonic at nondot.org Mon Oct 12 16:55:37 2009
From: tonic at nondot.org (Tanya Lattner)
Date: Mon, 12 Oct 2009 16:55:37 -0500
Subject: [llvm-commits] CVS: llvm-www/devmtg/2009-10/index.html
Message-ID: <200910122155.n9CLtbNa028404@zion.cs.uiuc.edu>
Changes in directory llvm-www/devmtg/2009-10:
index.html updated: 1.2 -> 1.3
---
Log message:
Be patient for videos.
---
Diffs of the changes: (+2 -1)
index.html | 3 ++-
1 files changed, 2 insertions(+), 1 deletion(-)
Index: llvm-www/devmtg/2009-10/index.html
diff -u llvm-www/devmtg/2009-10/index.html:1.2 llvm-www/devmtg/2009-10/index.html:1.3
--- llvm-www/devmtg/2009-10/index.html:1.2 Mon Oct 12 16:52:21 2009
+++ llvm-www/devmtg/2009-10/index.html Mon Oct 12 16:55:20 2009
@@ -41,6 +41,7 @@
major LLVM subsystems and talks on applications of LLVM for various
specific projects.
+
Videos will take 2-4 weeks from the meeting to appear. Please be patient.
@@ -248,7 +249,7 @@
src="http://jigsaw.w3.org/css-validator/images/vcss" alt="Valid CSS!">
- Last modified: $Date: 2009/10/12 21:52:21 $
+ Last modified: $Date: 2009/10/12 21:55:20 $
From tonic at nondot.org Mon Oct 12 16:57:25 2009
From: tonic at nondot.org (Tanya Lattner)
Date: Mon, 12 Oct 2009 16:57:25 -0500
Subject: [llvm-commits] CVS: llvm-www/devmtg/2009-10/index.html
Message-ID: <200910122157.n9CLvPlI028496@zion.cs.uiuc.edu>
Changes in directory llvm-www/devmtg/2009-10:
index.html updated: 1.3 -> 1.4
---
Log message:
Non breaking space.
---
Diffs of the changes: (+2 -2)
index.html | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
Index: llvm-www/devmtg/2009-10/index.html
diff -u llvm-www/devmtg/2009-10/index.html:1.3 llvm-www/devmtg/2009-10/index.html:1.4
--- llvm-www/devmtg/2009-10/index.html:1.3 Mon Oct 12 16:55:20 2009
+++ llvm-www/devmtg/2009-10/index.html Mon Oct 12 16:57:09 2009
@@ -204,7 +204,7 @@
ftBound: Highly Compatible and Complete Spatial Memory Safety for C -
@@ -249,7 +249,7 @@
src="http://jigsaw.w3.org/css-validator/images/vcss" alt="Valid CSS!">
- Last modified: $Date: 2009/10/12 21:55:20 $
+ Last modified: $Date: 2009/10/12 21:57:09 $
From tonic at nondot.org Mon Oct 12 16:59:40 2009
From: tonic at nondot.org (Tanya Lattner)
Date: Mon, 12 Oct 2009 16:59:40 -0500
Subject: [llvm-commits] CVS:
llvm-www/devmtg/2009-10/Petersen_OptimizingActionScriptBytecode.pdf
Message-ID: <200910122159.n9CLxeKw028669@zion.cs.uiuc.edu>
Changes in directory llvm-www/devmtg/2009-10:
Petersen_OptimizingActionScriptBytecode.pdf added (r1.1)
---
Log message:
Add Petersen talk.
---
Diffs of the changes: (+0 -0)
Petersen_OptimizingActionScriptBytecode.pdf | 0
1 files changed
Index: llvm-www/devmtg/2009-10/Petersen_OptimizingActionScriptBytecode.pdf
From tonic at nondot.org Mon Oct 12 17:02:52 2009
From: tonic at nondot.org (Tanya Lattner)
Date: Mon, 12 Oct 2009 17:02:52 -0500
Subject: [llvm-commits] CVS: llvm-www/devmtg/talkInfo.php
Message-ID: <200910122202.n9CM2quL028851@zion.cs.uiuc.edu>
Changes in directory llvm-www/devmtg:
talkInfo.php updated: 1.1 -> 1.2
---
Log message:
Its an int.
---
Diffs of the changes: (+1 -1)
talkInfo.php | 2 +-
1 files changed, 1 insertion(+), 1 deletion(-)
Index: llvm-www/devmtg/talkInfo.php
diff -u llvm-www/devmtg/talkInfo.php:1.1 llvm-www/devmtg/talkInfo.php:1.2
--- llvm-www/devmtg/talkInfo.php:1.1 Thu Oct 1 21:16:05 2009
+++ llvm-www/devmtg/talkInfo.php Mon Oct 12 17:02:37 2009
@@ -8,7 +8,7 @@
virtual("../header.incl");
?>
-$id = $_GET['id'];
+$id = (int)$_GET['id'];
$sql = "SELECT lastName, firstName, organization, title, summary from presenters WHERE id=$id";
$results = mysql_query($sql);
From evan.cheng at apple.com Mon Oct 12 17:03:35 2009
From: evan.cheng at apple.com (Evan Cheng)
Date: Mon, 12 Oct 2009 15:03:35 -0700
Subject: [llvm-commits] [llvm] r83902 -
/llvm/trunk/lib/Target/ARM/ARMConstantIslandPass.cpp
In-Reply-To: <5435A54B-30DB-43F9-BBB4-81DA4DED3CCB@apple.com>
References: <200910122123.n9CLNGLs026827@zion.cs.uiuc.edu>
<5435A54B-30DB-43F9-BBB4-81DA4DED3CCB@apple.com>
Message-ID: <33316BD2-5E02-4864-B981-16FE9C130585@apple.com>
On Oct 12, 2009, at 2:54 PM, Dale Johannesen wrote:
>
> On Oct 12, 2009, at 2:23 PMPDT, Bob Wilson wrote:
>
>> Author: bwilson
>> Date: Mon Oct 12 16:23:15 2009
>> New Revision: 83902
>>
>> URL: http://llvm.org/viewvc/llvm-project?rev=83902&view=rev
>> Log:
>> Last week, ARMConstantIslandPass was failing to converge for the
>> MultiSource/Benchmarks/MiBench/automotive-susan test. The failure has
>> since been masked by an unrelated change (just randomly), so I don't
>> have
>> a testcase for this now. Radar 7291928.
>
> Thanks for tracking this down and fixing it. The last person to hit
> it was not so brave; can we get rid of 78377 now?
Why do we want to get rid of 78377? Error out is always better than infinite looping. It's still theoretically possible there is another bug that can cause it not to converge.
Evan
>
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
From tonic at nondot.org Mon Oct 12 17:04:03 2009
From: tonic at nondot.org (Tanya Lattner)
Date: Mon, 12 Oct 2009 17:04:03 -0500
Subject: [llvm-commits] CVS: llvm-www/devmtg/2009-10/index.html
Message-ID: <200910122204.n9CM436V028943@zion.cs.uiuc.edu>
Changes in directory llvm-www/devmtg/2009-10:
index.html updated: 1.4 -> 1.5
---
Log message:
Fix title.
---
Diffs of the changes: (+2 -2)
index.html | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
Index: llvm-www/devmtg/2009-10/index.html
diff -u llvm-www/devmtg/2009-10/index.html:1.4 llvm-www/devmtg/2009-10/index.html:1.5
--- llvm-www/devmtg/2009-10/index.html:1.4 Mon Oct 12 16:57:09 2009
+++ llvm-www/devmtg/2009-10/index.html Mon Oct 12 17:03:46 2009
@@ -207,7 +207,7 @@
[PPT Slides]
Santosh Nagarakatte University of Pennsylvania
-
ftBound: Highly Compatible and Complete Spatial Memory Safety for C -
+
SoftBound: Highly Compatible and Complete Spatial Memory Safety for C -
The serious bugs and security vulnerabilities facilitated by C/C++???s lack of bounds checking are well known, yet C and C++ remain in widespread use. Unfortunately, C???s arbitrary pointer arithmetic, conflation of pointers and arrays, and programmer-visible memory layout make retrofitting C/C++ with spatial safety guarantees extremely challenging. Existing approaches suffer from incompleteness, have high runtime overhead, or require non-trivial changes to the C source code. Thus far, these deficiencies have prevented widespread adoption of such techniques. In this talk, I will present SoftBound, a compile-time transformation for enforcing spatial safety of C. SoftBound records base and bound information for every pointer as disjoint metadata. This decoupling enables SoftBound to provide spatial safety without requiring changes to C source code. SoftBound is a software-only approach and performs metadata manipulation only when loading or storing pointer values. I will !
also provide a brief description of the formal proof and llvm implementation. SoftBound???s full checking mode provides complete spatial violation detection with 67% runtime overhead on average. To further reduce overheads, SoftBound has a store-only checking mode that successfully detects all the security vulnerabilities in a test suite at the cost of only 22% runtime overhead on average.
@@ -249,7 +249,7 @@
src="http://jigsaw.w3.org/css-validator/images/vcss" alt="Valid CSS!">
- Last modified: $Date: 2009/10/12 21:57:09 $
+ Last modified: $Date: 2009/10/12 22:03:46 $
From bob.wilson at apple.com Mon Oct 12 17:01:58 2009
From: bob.wilson at apple.com (Bob Wilson)
Date: Mon, 12 Oct 2009 15:01:58 -0700
Subject: [llvm-commits] [llvm] r83902 -
/llvm/trunk/lib/Target/ARM/ARMConstantIslandPass.cpp
In-Reply-To: <5435A54B-30DB-43F9-BBB4-81DA4DED3CCB@apple.com>
References: <200910122123.n9CLNGLs026827@zion.cs.uiuc.edu>
<5435A54B-30DB-43F9-BBB4-81DA4DED3CCB@apple.com>
Message-ID:
On Oct 12, 2009, at 2:54 PM, Dale Johannesen wrote:
>
> On Oct 12, 2009, at 2:23 PMPDT, Bob Wilson wrote:
>
>> Author: bwilson
>> Date: Mon Oct 12 16:23:15 2009
>> New Revision: 83902
>>
>> URL: http://llvm.org/viewvc/llvm-project?rev=83902&view=rev
>> Log:
>> Last week, ARMConstantIslandPass was failing to converge for the
>> MultiSource/Benchmarks/MiBench/automotive-susan test. The failure
>> has
>> since been masked by an unrelated change (just randomly), so I
>> don't have
>> a testcase for this now. Radar 7291928.
>
> Thanks for tracking this down and fixing it. The last person to hit
> it was not so brave; can we get rid of 78377 now?
>
You're welcome. I'm a big fan of 78377 (the patch that causes the
compiler to fail instead of running forever when the pass doesn't
converge). It should hopefully not matter but there's always a chance
that new bugs will creep in.... If (or maybe I should say "when")
that happens, it's very bad for the compiler to hang.
From tonic at nondot.org Mon Oct 12 17:08:55 2009
From: tonic at nondot.org (Tanya Lattner)
Date: Mon, 12 Oct 2009 17:08:55 -0500
Subject: [llvm-commits] CVS: llvm-www/devmtg/2009-10/index.html
Message-ID: <200910122208.n9CM8t3V029150@zion.cs.uiuc.edu>
Changes in directory llvm-www/devmtg/2009-10:
index.html updated: 1.5 -> 1.6
---
Log message:
Shorten descriptions.
---
Diffs of the changes: (+6 -5)
index.html | 11 ++++++-----
1 files changed, 6 insertions(+), 5 deletions(-)
Index: llvm-www/devmtg/2009-10/index.html
diff -u llvm-www/devmtg/2009-10/index.html:1.5 llvm-www/devmtg/2009-10/index.html:1.6
--- llvm-www/devmtg/2009-10/index.html:1.5 Mon Oct 12 17:03:46 2009
+++ llvm-www/devmtg/2009-10/index.html Mon Oct 12 17:08:39 2009
@@ -88,7 +88,7 @@
Nicolas Geoffray Universite Pierre et Marie Curie
Precise and efficient garbage collection in VMKit with MMTk -
- This talk will describe how we have added precise garbage collection in VMKit, both in the JVM and .Net runtime. The work continues in the spirit of VMKit, in that the garbage collector is an external library provided by others. We have used MMTk, a garbage collector written in Java to provide efficient and precise garbage collection. The talk will give a step by step explanation on how the new system was implemented (using LLVM as an ahead of time compiler for Java, using the LLVM GC framework, creating stack maps at runtime, etc), and provide a tutorial on how this can be adopted by other kinds of VMs implemented with LLVM. Additionally, I will show the new performance results with the new garbage collector. The new system continues to support big applications (eclipse, tomcat, DaCapo benchmarks), and provides way better performance than before.
+ This talk will describe how we have added precise garbage collection in VMKit, both in the JVM and .Net runtime. The work continues in the spirit of VMKit, in that the garbage collector is an external library provided by others. We have used MMTk, a garbage collector written in Java to provide efficient and precise garbage collection. The talk will give a step by step explanation on how the new system was implemented and provide a tutorial on how this can be adopted by other kinds of VMs implemented with LLVM. Additionally, I will show the new performance results with the new garbage collector.
CoVaC: Compiler Validation by Program Analysis of the Cross-Product - I
- n this talk, I am going to present CoVaC, which is a framework for formal verification of the compiler optimization phase, and give a brief overview of the prototype tool, which has been developed on top of LLVM 2.0. The CoVaC framework checks that optimization passes preserve semantics of the program being compiled by proving that the unoptimized program is equivalent to the optimized one. To leverage existing program analysis techniques, we reduce the equivalence checking problem to analysis of one system - a cross-product of the two input programs. Unlike existing frameworks, CoVaC accommodates absence of compiler annotations and handles most of the classical intraprocedural optimizations such as constant folding, reassociation, common subexpression elimination, code motion, dead code elimination, branch optimizations, and others. The talk is based on the following paper: Compiler Validation by Program Analysis of the Cross-Product, Anna Zaks and Amir Pnueli, FM'08
+
CoVaC: Compiler Validation by Program Analysis of the Cross-Product -
+ CoVaC is a framework for formal verification of the compiler optimization phase. This talk gives a brief overview of the prototype tool, which has been developed on top of LLVM 2.0. The CoVaC framework checks that optimization passes preserve semantics of the program being compiled by proving that the unoptimized program is equivalent to the optimized one. To leverage existing program analysis techniques, we reduce the equivalence checking problem to analysis of one system - a cross-product of the two input programs.
+The talk is based on the following paper: Compiler Validation by Program Analysis of the Cross-Product, Anna Zaks and Amir Pnueli, FM'08
@@ -208,7 +209,7 @@
Santosh Nagarakatte University of Pennsylvania
SoftBound: Highly Compatible and Complete Spatial Memory Safety for C -
- The serious bugs and security vulnerabilities facilitated by C/C++???s lack of bounds checking are well known, yet C and C++ remain in widespread use. Unfortunately, C???s arbitrary pointer arithmetic, conflation of pointers and arrays, and programmer-visible memory layout make retrofitting C/C++ with spatial safety guarantees extremely challenging. Existing approaches suffer from incompleteness, have high runtime overhead, or require non-trivial changes to the C source code. Thus far, these deficiencies have prevented widespread adoption of such techniques. In this talk, I will present SoftBound, a compile-time transformation for enforcing spatial safety of C. SoftBound records base and bound information for every pointer as disjoint metadata. This decoupling enables SoftBound to provide spatial safety without requiring changes to C source code. SoftBound is a software-only approach and performs metadata manipulation only when loading or storing pointer values. I will !
also provide a brief description of the formal proof and llvm implementation. SoftBound???s full checking mode provides complete spatial violation detection with 67% runtime overhead on average. To further reduce overheads, SoftBound has a store-only checking mode that successfully detects all the security vulnerabilities in a test suite at the cost of only 22% runtime overhead on average.
+SoftBound is a compile-time transformation for enforcing spatial safety of C. SoftBound records base and bound information for every pointer as disjoint metadata. This decoupling enables SoftBound to provide spatial safety without requiring changes to C source code. SoftBound is a software-only approach and performs metadata manipulation only when loading or storing pointer values. This talk provides a brief description of the formal proof and llvm implementation.
@@ -249,7 +250,7 @@
src="http://jigsaw.w3.org/css-validator/images/vcss" alt="Valid CSS!">
- Last modified: $Date: 2009/10/12 22:03:46 $
+ Last modified: $Date: 2009/10/12 22:08:39 $
From evan.cheng at apple.com Mon Oct 12 17:25:23 2009
From: evan.cheng at apple.com (Evan Cheng)
Date: Mon, 12 Oct 2009 22:25:23 -0000
Subject: [llvm-commits] [llvm] r83908 -
/llvm/trunk/lib/Transforms/Scalar/LICM.cpp
Message-ID: <200910122225.n9CMPN5e029827@zion.cs.uiuc.edu>
Author: evancheng
Date: Mon Oct 12 17:25:23 2009
New Revision: 83908
URL: http://llvm.org/viewvc/llvm-project?rev=83908&view=rev
Log:
Make licm debug message readable.
Modified:
llvm/trunk/lib/Transforms/Scalar/LICM.cpp
Modified: llvm/trunk/lib/Transforms/Scalar/LICM.cpp
URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/lib/Transforms/Scalar/LICM.cpp?rev=83908&r1=83907&r2=83908&view=diff
==============================================================================
--- llvm/trunk/lib/Transforms/Scalar/LICM.cpp (original)
+++ llvm/trunk/lib/Transforms/Scalar/LICM.cpp Mon Oct 12 17:25:23 2009
@@ -605,7 +605,8 @@
/// that is safe to hoist, this instruction is called to do the dirty work.
///
void LICM::hoist(Instruction &I) {
- DEBUG(errs() << "LICM hoisting to " << Preheader->getName() << ": " << I);
+ DEBUG(errs() << "LICM hoisting to " << Preheader->getName() << ": "
+ << I << "\n");
// Remove the instruction from its current basic block... but don't delete the
// instruction.
From enderby at apple.com Mon Oct 12 17:39:55 2009
From: enderby at apple.com (Kevin Enderby)
Date: Mon, 12 Oct 2009 22:39:55 -0000
Subject: [llvm-commits] [llvm] r83915 -
/llvm/trunk/lib/Target/ARM/AsmParser/ARMAsmParser.cpp
Message-ID: <200910122239.n9CMdtSt030481@zion.cs.uiuc.edu>
Author: enderby
Date: Mon Oct 12 17:39:54 2009
New Revision: 83915
URL: http://llvm.org/viewvc/llvm-project?rev=83915&view=rev
Log:
Fix a problem in the code where ARMAsmParser::ParseShift() second argument
should have been a pointer to a reference.
Modified:
llvm/trunk/lib/Target/ARM/AsmParser/ARMAsmParser.cpp
Modified: llvm/trunk/lib/Target/ARM/AsmParser/ARMAsmParser.cpp
URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/lib/Target/ARM/AsmParser/ARMAsmParser.cpp?rev=83915&r1=83914&r2=83915&view=diff
==============================================================================
--- llvm/trunk/lib/Target/ARM/AsmParser/ARMAsmParser.cpp (original)
+++ llvm/trunk/lib/Target/ARM/AsmParser/ARMAsmParser.cpp Mon Oct 12 17:39:54 2009
@@ -50,7 +50,7 @@
bool ParseMemory(ARMOperand &Op);
- bool ParseShift(enum ShiftType *St, const MCExpr *ShiftAmount);
+ bool ParseShift(enum ShiftType *St, const MCExpr *&ShiftAmount);
bool ParseOperand(ARMOperand &Op);
@@ -414,7 +414,7 @@
/// ( lsl | lsr | asr | ror ) , # shift_amount
/// rrx
/// and returns true if it parses a shift otherwise it returns false.
-bool ARMAsmParser::ParseShift(ShiftType *St, const MCExpr *ShiftAmount) {
+bool ARMAsmParser::ParseShift(ShiftType *St, const MCExpr *&ShiftAmount) {
const AsmToken &Tok = getLexer().getTok();
if (Tok.isNot(AsmToken::Identifier))
return true;
From bob.wilson at apple.com Mon Oct 12 17:49:05 2009
From: bob.wilson at apple.com (Bob Wilson)
Date: Mon, 12 Oct 2009 22:49:05 -0000
Subject: [llvm-commits] [llvm] r83916 -
/llvm/trunk/lib/Target/ARM/ARMConstantIslandPass.cpp
Message-ID: <200910122249.n9CMn5sW030870@zion.cs.uiuc.edu>
Author: bwilson
Date: Mon Oct 12 17:49:05 2009
New Revision: 83916
URL: http://llvm.org/viewvc/llvm-project?rev=83916&view=rev
Log:
Delete a comment that makes no sense to me. The statement that moving a CPE
before its reference is only supported on ARM has not been true for a while.
In fact, until recently, that was only supported for Thumb. Besides that,
CPEs are always a multiple of 4 bytes in size, so inserting a CPE should have
no effect on Thumb alignment.
Modified:
llvm/trunk/lib/Target/ARM/ARMConstantIslandPass.cpp
Modified: llvm/trunk/lib/Target/ARM/ARMConstantIslandPass.cpp
URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/lib/Target/ARM/ARMConstantIslandPass.cpp?rev=83916&r1=83915&r2=83916&view=diff
==============================================================================
--- llvm/trunk/lib/Target/ARM/ARMConstantIslandPass.cpp (original)
+++ llvm/trunk/lib/Target/ARM/ARMConstantIslandPass.cpp Mon Oct 12 17:49:05 2009
@@ -757,8 +757,7 @@
BBSizes[Water->getNumber()];
// If the CPE is to be inserted before the instruction, that will raise
- // the offset of the instruction. (Currently applies only to ARM, so
- // no alignment compensation attempted here.)
+ // the offset of the instruction.
if (CPEOffset < UserOffset)
UserOffset += U.CPEMI->getOperand(2).getImm();
From enderby at apple.com Mon Oct 12 17:51:50 2009
From: enderby at apple.com (Kevin Enderby)
Date: Mon, 12 Oct 2009 22:51:50 -0000
Subject: [llvm-commits] [llvm] r83917 -
/llvm/trunk/lib/Target/ARM/AsmParser/ARMAsmParser.cpp
Message-ID: <200910122251.n9CMpobJ030971@zion.cs.uiuc.edu>
Author: enderby
Date: Mon Oct 12 17:51:49 2009
New Revision: 83917
URL: http://llvm.org/viewvc/llvm-project?rev=83917&view=rev
Log:
Fix two warnings about unused variables that are only used in assert() calls.
Modified:
llvm/trunk/lib/Target/ARM/AsmParser/ARMAsmParser.cpp
Modified: llvm/trunk/lib/Target/ARM/AsmParser/ARMAsmParser.cpp
URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/lib/Target/ARM/AsmParser/ARMAsmParser.cpp?rev=83917&r1=83916&r2=83917&view=diff
==============================================================================
--- llvm/trunk/lib/Target/ARM/AsmParser/ARMAsmParser.cpp (original)
+++ llvm/trunk/lib/Target/ARM/AsmParser/ARMAsmParser.cpp Mon Oct 12 17:51:49 2009
@@ -216,8 +216,8 @@
// Try to parse a register list. The first token must be a '{' when called
// for now.
bool ARMAsmParser::ParseRegisterList(ARMOperand &Op) {
- const AsmToken &LCurlyTok = getLexer().getTok();
- assert(LCurlyTok.is(AsmToken::LCurly) && "Token is not an Left Curly Brace");
+ assert(getLexer().getTok().is(AsmToken::LCurly) &&
+ "Token is not an Left Curly Brace");
getLexer().Lex(); // Eat left curly brace token.
const AsmToken &RegTok = getLexer().getTok();
@@ -264,8 +264,8 @@
// TODO Only preindexing and postindexing addressing are started, unindexed
// with option, etc are still to do.
bool ARMAsmParser::ParseMemory(ARMOperand &Op) {
- const AsmToken &LBracTok = getLexer().getTok();
- assert(LBracTok.is(AsmToken::LBrac) && "Token is not an Left Bracket");
+ assert(getLexer().getTok().is(AsmToken::LBrac) &&
+ "Token is not an Left Bracket");
getLexer().Lex(); // Eat left bracket token.
const AsmToken &BaseRegTok = getLexer().getTok();
From dpatel at apple.com Mon Oct 12 18:10:55 2009
From: dpatel at apple.com (Devang Patel)
Date: Mon, 12 Oct 2009 23:10:55 -0000
Subject: [llvm-commits] [llvm] r83921 -
/llvm/trunk/lib/CodeGen/SelectionDAG/SelectionDAGISel.cpp
Message-ID: <200910122310.n9CNAtpH031737@zion.cs.uiuc.edu>
Author: dpatel
Date: Mon Oct 12 18:10:55 2009
New Revision: 83921
URL: http://llvm.org/viewvc/llvm-project?rev=83921&view=rev
Log:
Set default location for a function if it is not set.
Modified:
llvm/trunk/lib/CodeGen/SelectionDAG/SelectionDAGISel.cpp
Modified: llvm/trunk/lib/CodeGen/SelectionDAG/SelectionDAGISel.cpp
URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/lib/CodeGen/SelectionDAG/SelectionDAGISel.cpp?rev=83921&r1=83920&r2=83921&view=diff
==============================================================================
--- llvm/trunk/lib/CodeGen/SelectionDAG/SelectionDAGISel.cpp (original)
+++ llvm/trunk/lib/CodeGen/SelectionDAG/SelectionDAGISel.cpp Mon Oct 12 18:10:55 2009
@@ -385,6 +385,8 @@
DILocation DILoc(Dbg);
DebugLoc Loc = ExtractDebugLocation(DILoc, MF->getDebugLocInfo());
SDL->setCurDebugLoc(Loc);
+ if (MF->getDefaultDebugLoc().isUnknown())
+ MF->setDefaultDebugLoc(Loc);
}
}
if (!isa(I))
From dpatel at apple.com Mon Oct 12 18:11:24 2009
From: dpatel at apple.com (Devang Patel)
Date: Mon, 12 Oct 2009 23:11:24 -0000
Subject: [llvm-commits] [llvm] r83922 -
/llvm/trunk/lib/CodeGen/AsmPrinter/DwarfDebug.cpp
Message-ID: <200910122311.n9CNBOAZ031772@zion.cs.uiuc.edu>
Author: dpatel
Date: Mon Oct 12 18:11:24 2009
New Revision: 83922
URL: http://llvm.org/viewvc/llvm-project?rev=83922&view=rev
Log:
Find enclosing subprogram info.
Modified:
llvm/trunk/lib/CodeGen/AsmPrinter/DwarfDebug.cpp
Modified: llvm/trunk/lib/CodeGen/AsmPrinter/DwarfDebug.cpp
URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/lib/CodeGen/AsmPrinter/DwarfDebug.cpp?rev=83922&r1=83921&r2=83922&view=diff
==============================================================================
--- llvm/trunk/lib/CodeGen/AsmPrinter/DwarfDebug.cpp (original)
+++ llvm/trunk/lib/CodeGen/AsmPrinter/DwarfDebug.cpp Mon Oct 12 18:11:24 2009
@@ -1894,6 +1894,24 @@
return !DbgScopeMap.empty();
}
+static DISubprogram getDISubprogram(MDNode *N) {
+
+ DIDescriptor D(N);
+ if (D.isNull())
+ return DISubprogram();
+
+ if (D.isCompileUnit())
+ return DISubprogram();
+
+ if (D.isSubprogram())
+ return DISubprogram(N);
+
+ if (D.isLexicalBlock())
+ return getDISubprogram(DILexicalBlock(N).getContext().getNode());
+
+ assert (0 && "Unexpected Descriptor!");
+}
+
/// BeginFunction - Gather pre-function debug information. Assumes being
/// emitted immediately after the function entry point.
void DwarfDebug::BeginFunction(MachineFunction *MF) {
@@ -1923,7 +1941,7 @@
if (!FDL.isUnknown()) {
DebugLocTuple DLT = MF->getDebugLocTuple(FDL);
unsigned LabelID = 0;
- DISubprogram SP(DLT.CompileUnit);
+ DISubprogram SP = getDISubprogram(DLT.CompileUnit);
if (!SP.isNull())
LabelID = RecordSourceLine(SP.getLineNumber(), 0, DLT.CompileUnit);
else
From dpatel at apple.com Mon Oct 12 18:22:09 2009
From: dpatel at apple.com (Devang Patel)
Date: Mon, 12 Oct 2009 23:22:09 -0000
Subject: [llvm-commits] [llvm] r83925 - in /llvm/trunk/include/llvm:
Analysis/DebugInfo.h CodeGen/MachineModuleInfo.h
Message-ID: <200910122322.n9CNMAUI032304@zion.cs.uiuc.edu>
Author: dpatel
Date: Mon Oct 12 18:22:09 2009
New Revision: 83925
URL: http://llvm.org/viewvc/llvm-project?rev=83925&view=rev
Log:
Enable "debug info attached to an instruction" mode.
Modified:
llvm/trunk/include/llvm/Analysis/DebugInfo.h
llvm/trunk/include/llvm/CodeGen/MachineModuleInfo.h
Modified: llvm/trunk/include/llvm/Analysis/DebugInfo.h
URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/include/llvm/Analysis/DebugInfo.h?rev=83925&r1=83924&r2=83925&view=diff
==============================================================================
--- llvm/trunk/include/llvm/Analysis/DebugInfo.h (original)
+++ llvm/trunk/include/llvm/Analysis/DebugInfo.h Mon Oct 12 18:22:09 2009
@@ -26,6 +26,8 @@
#include "llvm/Support/Dwarf.h"
#include "llvm/Support/ValueHandle.h"
+#define ATTACH_DEBUG_INFO_TO_AN_INSN 1
+
namespace llvm {
class BasicBlock;
class Constant;
Modified: llvm/trunk/include/llvm/CodeGen/MachineModuleInfo.h
URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/include/llvm/CodeGen/MachineModuleInfo.h?rev=83925&r1=83924&r2=83925&view=diff
==============================================================================
--- llvm/trunk/include/llvm/CodeGen/MachineModuleInfo.h (original)
+++ llvm/trunk/include/llvm/CodeGen/MachineModuleInfo.h Mon Oct 12 18:22:09 2009
@@ -44,6 +44,8 @@
#include "llvm/Pass.h"
#include "llvm/Metadata.h"
+#define ATTACH_DEBUG_INFO_TO_AN_INSN 1
+
namespace llvm {
//===----------------------------------------------------------------------===//
From sabre at nondot.org Mon Oct 12 18:56:32 2009
From: sabre at nondot.org (Chris Lattner)
Date: Mon, 12 Oct 2009 18:56:32 -0500
Subject: [llvm-commits] CVS: llvm-www/devmtg/index.html
Message-ID: <200910122356.n9CNuW2J001154@zion.cs.uiuc.edu>
Changes in directory llvm-www/devmtg:
index.html updated: 1.6 -> 1.7
---
Log message:
fix link, the meeting already happened.
---
Diffs of the changes: (+5 -6)
index.html | 11 +++++------
1 files changed, 5 insertions(+), 6 deletions(-)
Index: llvm-www/devmtg/index.html
diff -u llvm-www/devmtg/index.html:1.6 llvm-www/devmtg/index.html:1.7
--- llvm-www/devmtg/index.html:1.6 Fri Jul 10 12:45:18 2009
+++ llvm-www/devmtg/index.html Mon Oct 12 18:55:33 2009
@@ -2,14 +2,13 @@
LLVM Developers' Meeting
-Upcoming Developers' Meeting: October 2, 2009 - Cupertino, CA, USA
-
The 'llvm.lifetime.start' intrinsic specifies the start of a memory
+ object's lifetime.
+
+
Arguments:
+
The first argument is a the size of the object, or -1 if it is variable
+ sized. The second argument is a pointer to the object.
+
+
Semantics:
+
This intrinsic indicates that before this point in the code, the value of the
+ memory pointed to by ptr is dead. This means that it is known to
+ never be used and has an undefined value. A load from the pointer that is
+ preceded by this intrinsic can be replaced with
+ 'undef'.
The 'llvm.lifetime.end' intrinsic specifies the end of a memory
+ object's lifetime.
+
+
Arguments:
+
The first argument is a the size of the object, or -1 if it is variable
+ sized. The second argument is a pointer to the object.
+
+
Semantics:
+
This intrinsic indicates that after this point in the code, the value of the
+ memory pointed to by ptr is dead. This means that it is known to
+ never be used and has an undefined value. Any stores into the memory object
+ following this intrinsic may be removed as dead.
+
+
The 'llvm.invariant.end' intrinsic specifies that the contents of
+ a memory object are mutable.
+
+
Arguments:
+
The first argument is the matching llvm.invariant.start intrinsic.
+ The second argument is a the size of the object, or -1 if it is variable
+ sized and the third argument is a pointer to the object.
+
+
Semantics:
+
This intrinsic indicates that the memory is mutable again.
+
+
+
General Intrinsics
Modified: llvm/trunk/include/llvm/Intrinsics.td
URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/include/llvm/Intrinsics.td?rev=83953&r1=83952&r2=83953&view=diff
==============================================================================
--- llvm/trunk/include/llvm/Intrinsics.td (original)
+++ llvm/trunk/include/llvm/Intrinsics.td Tue Oct 13 02:03:23 2009
@@ -421,6 +421,22 @@
[IntrWriteArgMem, NoCapture<0>]>,
GCCBuiltin<"__sync_fetch_and_umax">;
+//===------------------------- Memory Use Markers -------------------------===//
+//
+def int_lifetime_start : Intrinsic<[llvm_void_ty],
+ [llvm_i64_ty, llvm_ptr_ty],
+ [IntrWriteArgMem, NoCapture<1>]>;
+def int_lifetime_end : Intrinsic<[llvm_void_ty],
+ [llvm_i64_ty, llvm_ptr_ty],
+ [IntrWriteArgMem, NoCapture<1>]>;
+def int_invariant_start : Intrinsic<[llvm_descriptor_ty],
+ [llvm_i64_ty, llvm_ptr_ty],
+ [IntrReadArgMem, NoCapture<1>]>;
+def int_invariant_end : Intrinsic<[llvm_void_ty],
+ [llvm_descriptor_ty, llvm_i64_ty,
+ llvm_ptr_ty],
+ [IntrWriteArgMem, NoCapture<2>]>;
+
//===-------------------------- Other Intrinsics --------------------------===//
//
def int_flt_rounds : Intrinsic<[llvm_i32_ty]>,
Added: llvm/trunk/test/Feature/memorymarkers.ll
URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/test/Feature/memorymarkers.ll?rev=83953&view=auto
==============================================================================
--- llvm/trunk/test/Feature/memorymarkers.ll (added)
+++ llvm/trunk/test/Feature/memorymarkers.ll Tue Oct 13 02:03:23 2009
@@ -0,0 +1,36 @@
+; RUN: llvm-as -disable-output < %s
+
+%"struct.std::pair" = type { i32, i32 }
+
+declare void @_Z3barRKi(i32*)
+
+declare void @llvm.lifetime.start(i64, i8* nocapture) nounwind
+declare void @llvm.lifetime.end(i64, i8* nocapture) nounwind
+declare {}* @llvm.invariant.start(i64, i8* nocapture) readonly nounwind
+declare void @llvm.invariant.end({}*, i64, i8* nocapture) nounwind
+
+define i32 @_Z4foo2v() nounwind {
+entry:
+ %x = alloca %"struct.std::pair"
+ %y = bitcast %"struct.std::pair"* %x to i8*
+
+ ;; Constructor starts here (this isn't needed since it is immediately
+ ;; preceded by an alloca, but shown for completeness).
+ call void @llvm.lifetime.start(i64 8, i8* %y)
+
+ %0 = getelementptr %"struct.std::pair"* %x, i32 0, i32 0
+ store i32 4, i32* %0, align 8
+ %1 = getelementptr %"struct.std::pair"* %x, i32 0, i32 1
+ store i32 5, i32* %1, align 4
+
+ ;; Constructor has finished here.
+ %inv = call {}* @llvm.invariant.start(i64 8, i8* %y)
+ call void @_Z3barRKi(i32* %0) nounwind
+ %2 = load i32* %0, align 8
+
+ ;; Destructor is run here.
+ call void @llvm.invariant.end({}* %inv, i64 8, i8* %y)
+ ;; Destructor is done here.
+ call void @llvm.lifetime.end(i64 8, i8* %y)
+ ret i32 %2
+}
From astifter-llvm at gmx.at Tue Oct 13 02:39:29 2009
From: astifter-llvm at gmx.at (Andreas Neustifter)
Date: Tue, 13 Oct 2009 09:39:29 +0200
Subject: [llvm-commits] Static Profile Patch
In-Reply-To:
References: <030E9AA3-1AF1-433F-8807-9628E7155939@apple.com> <98736D45-B8BE-4616-82EC-EECE7A25AE40@apple.com>
Message-ID: <4AD42EB1.7020305@gmx.at>
Hi Andrei!
Sorry, took me a while to get to this.
The implementation looks good and solid, I haven't had time for an
in-depth review, but from what I gather the Wu's algorithm is properly
implemented.
The patch does not build against revision 83533 (2009-10-08 09:01:46)
with the build complaining about cyclic dependencies between
libLLVMAnalysis.a and libLLVMipa.a. Any ideas about this?
Andi
From nicholas at mxc.ca Tue Oct 13 02:48:39 2009
From: nicholas at mxc.ca (Nick Lewycky)
Date: Tue, 13 Oct 2009 07:48:39 -0000
Subject: [llvm-commits] [llvm] r83959 - in /llvm/trunk:
lib/Analysis/BasicAliasAnalysis.cpp
test/Analysis/BasicAA/2009-10-13-AtomicModRef.ll
Message-ID: <200910130748.n9D7mdF0014001@zion.cs.uiuc.edu>
Author: nicholas
Date: Tue Oct 13 02:48:38 2009
New Revision: 83959
URL: http://llvm.org/viewvc/llvm-project?rev=83959&view=rev
Log:
Teach BasicAA a little something about the atomic intrinsics: they can only
modify through the pointer they're given.
Added:
llvm/trunk/test/Analysis/BasicAA/2009-10-13-AtomicModRef.ll
Modified:
llvm/trunk/lib/Analysis/BasicAliasAnalysis.cpp
Modified: llvm/trunk/lib/Analysis/BasicAliasAnalysis.cpp
URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/lib/Analysis/BasicAliasAnalysis.cpp?rev=83959&r1=83958&r2=83959&view=diff
==============================================================================
--- llvm/trunk/lib/Analysis/BasicAliasAnalysis.cpp (original)
+++ llvm/trunk/lib/Analysis/BasicAliasAnalysis.cpp Tue Oct 13 02:48:38 2009
@@ -284,6 +284,27 @@
if (!passedAsArg)
return NoModRef;
}
+
+ if (IntrinsicInst *II = dyn_cast(CS.getInstruction())) {
+ switch (II->getIntrinsicID()) {
+ default: break;
+ case Intrinsic::atomic_cmp_swap:
+ case Intrinsic::atomic_swap:
+ case Intrinsic::atomic_load_add:
+ case Intrinsic::atomic_load_sub:
+ case Intrinsic::atomic_load_and:
+ case Intrinsic::atomic_load_nand:
+ case Intrinsic::atomic_load_or:
+ case Intrinsic::atomic_load_xor:
+ case Intrinsic::atomic_load_max:
+ case Intrinsic::atomic_load_min:
+ case Intrinsic::atomic_load_umax:
+ case Intrinsic::atomic_load_umin:
+ if (alias(II->getOperand(1), Size, P, Size) == NoAlias)
+ return NoModRef;
+ break;
+ }
+ }
}
// The AliasAnalysis base class has some smarts, lets use them.
Added: llvm/trunk/test/Analysis/BasicAA/2009-10-13-AtomicModRef.ll
URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/test/Analysis/BasicAA/2009-10-13-AtomicModRef.ll?rev=83959&view=auto
==============================================================================
--- llvm/trunk/test/Analysis/BasicAA/2009-10-13-AtomicModRef.ll (added)
+++ llvm/trunk/test/Analysis/BasicAA/2009-10-13-AtomicModRef.ll Tue Oct 13 02:48:38 2009
@@ -0,0 +1,16 @@
+; RUN: opt -gvn -S < %s | FileCheck %s
+
+declare i8 @llvm.atomic.load.add.i8.p0i8(i8*, i8)
+
+define void @foo(i8* %ptr) {
+ %P = getelementptr i8* %ptr, i32 0
+ %Q = getelementptr i8* %ptr, i32 1
+; CHECK: getelementptr
+ %X = load i8* %P
+; CHECK: = load
+ %Y = call i8 @llvm.atomic.load.add.i8.p0i8(i8* %Q, i8 1)
+ %Z = load i8* %P
+; CHECK-NOT: = load
+ ret void
+; CHECK: ret void
+}
From baldrick at free.fr Tue Oct 13 02:51:31 2009
From: baldrick at free.fr (Duncan Sands)
Date: Tue, 13 Oct 2009 09:51:31 +0200
Subject: [llvm-commits] [llvm] r83953 - in /llvm/trunk:
docs/LangRef.html include/llvm/Intrinsics.td test/Feature/memorymarkers.ll
In-Reply-To: <200910130703.n9D73NSw007024@zion.cs.uiuc.edu>
References: <200910130703.n9D73NSw007024@zion.cs.uiuc.edu>
Message-ID: <4AD43183.7000906@free.fr>
Hi Nick,
> +
The first argument is the matching llvm.invariant.start intrinsic.
> + The second argument is a the size of the object, or -1 if it is variable
a the -> the
> + sized and the third argument is a pointer to the object.
sized and the -> size. The
Ciao,
Duncan.
From baldrick at free.fr Tue Oct 13 02:54:08 2009
From: baldrick at free.fr (Duncan Sands)
Date: Tue, 13 Oct 2009 09:54:08 +0200
Subject: [llvm-commits] [llvm] r83953 - in /llvm/trunk:
docs/LangRef.html include/llvm/Intrinsics.td test/Feature/memorymarkers.ll
In-Reply-To: <200910130703.n9D73NSw007024@zion.cs.uiuc.edu>
References: <200910130703.n9D73NSw007024@zion.cs.uiuc.edu>
Message-ID: <4AD43220.90901@free.fr>
Hi Nick, probably it doesn't matter but the first argument here is also
not captured (the "descriptor").
> +def int_invariant_end : Intrinsic<[llvm_void_ty],
> + [llvm_descriptor_ty, llvm_i64_ty,
> + llvm_ptr_ty],
> + [IntrWriteArgMem, NoCapture<2>]>;
Ciao,
Duncan.
From baldrick at free.fr Tue Oct 13 02:56:19 2009
From: baldrick at free.fr (Duncan Sands)
Date: Tue, 13 Oct 2009 09:56:19 +0200
Subject: [llvm-commits] [llvm] r83959 - in /llvm/trunk:
lib/Analysis/BasicAliasAnalysis.cpp
test/Analysis/BasicAA/2009-10-13-AtomicModRef.ll
In-Reply-To: <200910130748.n9D7mdF0014001@zion.cs.uiuc.edu>
References: <200910130748.n9D7mdF0014001@zion.cs.uiuc.edu>
Message-ID: <4AD432A3.9010602@free.fr>
Hi Nick,
> Teach BasicAA a little something about the atomic intrinsics: they can only
> modify through the pointer they're given.
how does that differ from IntrWriteArgMem? I thought the AA core
already had some logic for this.
Ciao,
Duncan.
From nicholas at mxc.ca Tue Oct 13 02:57:34 2009
From: nicholas at mxc.ca (Nick Lewycky)
Date: Tue, 13 Oct 2009 07:57:34 -0000
Subject: [llvm-commits] [llvm] r83960 - in /llvm/trunk: docs/LangRef.html
lib/VMCore/Verifier.cpp
Message-ID: <200910130757.n9D7vYDI017071@zion.cs.uiuc.edu>
Author: nicholas
Date: Tue Oct 13 02:57:33 2009
New Revision: 83960
URL: http://llvm.org/viewvc/llvm-project?rev=83960&view=rev
Log:
Force memory use markers to have a ConstantInt for the size argument.
Modified:
llvm/trunk/docs/LangRef.html
llvm/trunk/lib/VMCore/Verifier.cpp
Modified: llvm/trunk/docs/LangRef.html
URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/docs/LangRef.html?rev=83960&r1=83959&r2=83960&view=diff
==============================================================================
--- llvm/trunk/docs/LangRef.html (original)
+++ llvm/trunk/docs/LangRef.html Tue Oct 13 02:57:33 2009
@@ -7018,8 +7018,9 @@
object's lifetime.
Arguments:
-
The first argument is a the size of the object, or -1 if it is variable
- sized. The second argument is a pointer to the object.
+
The first argument is a constant integer representing the size of the
+ object, or -1 if it is variable sized. The second argument is a pointer to
+ the object.
Semantics:
This intrinsic indicates that before this point in the code, the value of the
@@ -7047,8 +7048,9 @@
object's lifetime.
Arguments:
-
The first argument is a the size of the object, or -1 if it is variable
- sized. The second argument is a pointer to the object.
+
The first argument is a constant integer representing the size of the
+ object, or -1 if it is variable sized. The second argument is a pointer to
+ the object.
Semantics:
This intrinsic indicates that after this point in the code, the value of the
@@ -7075,8 +7077,9 @@
a memory object will not change.
Arguments:
-
The first argument is a the size of the object, or -1 if it is variable
- sized. The second argument is a pointer to the object.
+
The first argument is a constant integer representing the size of the
+ object, or -1 if it is variable sized. The second argument is a pointer to
+ the object.
Semantics:
This intrinsic indicates that until an llvm.invariant.end that uses
@@ -7103,8 +7106,9 @@
Arguments:
The first argument is the matching llvm.invariant.start intrinsic.
- The second argument is a the size of the object, or -1 if it is variable
- sized and the third argument is a pointer to the object.
+ The second argument is a constant integer representing the size of the
+ object, or -1 if it is variable sized and the third argument is a pointer
+ to the object.
Semantics:
This intrinsic indicates that the memory is mutable again.
Modified: llvm/trunk/lib/VMCore/Verifier.cpp
URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/lib/VMCore/Verifier.cpp?rev=83960&r1=83959&r2=83960&view=diff
==============================================================================
--- llvm/trunk/lib/VMCore/Verifier.cpp (original)
+++ llvm/trunk/lib/VMCore/Verifier.cpp Tue Oct 13 02:57:33 2009
@@ -1578,6 +1578,17 @@
"llvm.stackprotector parameter #2 must resolve to an alloca.",
&CI);
break;
+ case Intrinsic::lifetime_start:
+ case Intrinsic::lifetime_end:
+ case Intrinsic::invariant_start:
+ Assert1(isa(CI.getOperand(1)),
+ "size argument of memory use markers must be a constant integer",
+ &CI);
+ break;
+ case Intrinsic::invariant_end:
+ Assert1(isa(CI.getOperand(2)),
+ "llvm.invariant.end parameter #2 must be a constant integer", &CI);
+ break;
}
}
From evan.cheng at apple.com Tue Oct 13 04:01:15 2009
From: evan.cheng at apple.com (Evan Cheng)
Date: Tue, 13 Oct 2009 02:01:15 -0700
Subject: [llvm-commits] [PATCH] Make ExecutionEngine automatically
remove global mappings on GlobalValue destruction
In-Reply-To: <0016363b7bded75fc30475c6559a@google.com>
References: <0016363b7bded75fc30475c6559a@google.com>
Message-ID: <6F95F744-B216-4EB0-9A6C-14ECF07FFB5E@apple.com>
Looks good to me. I'd preferred if "state" can be renamed to something
like EEState though.
Evan
On Oct 12, 2009, at 5:43 PM, jyasskin at gmail.com wrote:
> Reviewers: ,
>
> Message:
> http://codereview.appspot.com/download/issue129074_5.diff
>
> This doesn't make the ExecutionEngine do everything perfectly on
> GlobalValue destruction (stubs still crash and machine code still
> leaks), but it's progress.
>
>
>
> Please review this at http://codereview.appspot.com/129074
>
> Affected files:
> M include/llvm/ExecutionEngine/ExecutionEngine.h
> M lib/ExecutionEngine/ExecutionEngine.cpp
> M unittests/ExecutionEngine/ExecutionEngineTest.cpp
>
>
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
From baldrick at free.fr Tue Oct 13 04:23:12 2009
From: baldrick at free.fr (Duncan Sands)
Date: Tue, 13 Oct 2009 09:23:12 -0000
Subject: [llvm-commits] [llvm] r83962 -
/llvm/trunk/unittests/ADT/APIntTest.cpp
Message-ID: <200910130923.n9D9NCsU025903@zion.cs.uiuc.edu>
Author: baldrick
Date: Tue Oct 13 04:23:11 2009
New Revision: 83962
URL: http://llvm.org/viewvc/llvm-project?rev=83962&view=rev
Log:
Pacify the compiler (signed with unsigned comparison) by making
these constants unsigned.
Modified:
llvm/trunk/unittests/ADT/APIntTest.cpp
Modified: llvm/trunk/unittests/ADT/APIntTest.cpp
URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/unittests/ADT/APIntTest.cpp?rev=83962&r1=83961&r2=83962&view=diff
==============================================================================
--- llvm/trunk/unittests/ADT/APIntTest.cpp (original)
+++ llvm/trunk/unittests/ADT/APIntTest.cpp Tue Oct 13 04:23:11 2009
@@ -316,14 +316,14 @@
}
TEST(APIntTest, Log2) {
- EXPECT_EQ(APInt(15, 7).logBase2(), 2);
- EXPECT_EQ(APInt(15, 7).ceilLogBase2(), 3);
+ EXPECT_EQ(APInt(15, 7).logBase2(), 2U);
+ EXPECT_EQ(APInt(15, 7).ceilLogBase2(), 3U);
EXPECT_EQ(APInt(15, 7).exactLogBase2(), -1);
- EXPECT_EQ(APInt(15, 8).logBase2(), 3);
- EXPECT_EQ(APInt(15, 8).ceilLogBase2(), 3);
+ EXPECT_EQ(APInt(15, 8).logBase2(), 3U);
+ EXPECT_EQ(APInt(15, 8).ceilLogBase2(), 3U);
EXPECT_EQ(APInt(15, 8).exactLogBase2(), 3);
- EXPECT_EQ(APInt(15, 9).logBase2(), 3);
- EXPECT_EQ(APInt(15, 9).ceilLogBase2(), 4);
+ EXPECT_EQ(APInt(15, 9).logBase2(), 3U);
+ EXPECT_EQ(APInt(15, 9).ceilLogBase2(), 4U);
EXPECT_EQ(APInt(15, 9).exactLogBase2(), -1);
}
From baldrick at free.fr Tue Oct 13 04:24:02 2009
From: baldrick at free.fr (Duncan Sands)
Date: Tue, 13 Oct 2009 09:24:02 -0000
Subject: [llvm-commits] [llvm] r83963 -
/llvm/trunk/include/llvm/Intrinsics.td
Message-ID: <200910130924.n9D9O2Uf025965@zion.cs.uiuc.edu>
Author: baldrick
Date: Tue Oct 13 04:24:02 2009
New Revision: 83963
URL: http://llvm.org/viewvc/llvm-project?rev=83963&view=rev
Log:
The eh.exception intrinsic only reads from memory, it doesn't
write to it.
Modified:
llvm/trunk/include/llvm/Intrinsics.td
Modified: llvm/trunk/include/llvm/Intrinsics.td
URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/include/llvm/Intrinsics.td?rev=83963&r1=83962&r2=83963&view=diff
==============================================================================
--- llvm/trunk/include/llvm/Intrinsics.td (original)
+++ llvm/trunk/include/llvm/Intrinsics.td Tue Oct 13 04:24:02 2009
@@ -289,7 +289,7 @@
//===------------------ Exception Handling Intrinsics----------------------===//
//
-def int_eh_exception : Intrinsic<[llvm_ptr_ty]>;
+def int_eh_exception : Intrinsic<[llvm_ptr_ty], [], [IntrReadMem]>;
def int_eh_selector_i32 : Intrinsic<[llvm_i32_ty],
[llvm_ptr_ty, llvm_ptr_ty, llvm_vararg_ty]>;
def int_eh_selector_i64 : Intrinsic<[llvm_i64_ty],
From bob.wilson at apple.com Tue Oct 13 10:27:23 2009
From: bob.wilson at apple.com (Bob Wilson)
Date: Tue, 13 Oct 2009 15:27:23 -0000
Subject: [llvm-commits] [llvm] r83973 -
/llvm/trunk/lib/Target/ARM/ARMInstrInfo.td
Message-ID: <200910131527.n9DFRNfB006079@zion.cs.uiuc.edu>
Author: bwilson
Date: Tue Oct 13 10:27:23 2009
New Revision: 83973
URL: http://llvm.org/viewvc/llvm-project?rev=83973&view=rev
Log:
Fix a tab. Thanks to Johnny Chen for pointing it out.
Modified:
llvm/trunk/lib/Target/ARM/ARMInstrInfo.td
Modified: llvm/trunk/lib/Target/ARM/ARMInstrInfo.td
URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/lib/Target/ARM/ARMInstrInfo.td?rev=83973&r1=83972&r2=83973&view=diff
==============================================================================
--- llvm/trunk/lib/Target/ARM/ARMInstrInfo.td (original)
+++ llvm/trunk/lib/Target/ARM/ARMInstrInfo.td Tue Oct 13 10:27:23 2009
@@ -397,7 +397,7 @@
IIC_iALUr, opc, "s $dst, $a, $b",
[(set GPR:$dst, (opnode GPR:$a, GPR:$b))]> {
let isCommutable = Commutable;
- let Inst{25} = 0;
+ let Inst{25} = 0;
}
def rs : AI1
Changes in directory llvm-www/ProjectsWithLLVM:
index.html updated: 1.51 -> 1.52
---
Log message:
xps is dead and x-p-s.org is a domain squatter now.
---
Diffs of the changes: (+0 -48)
index.html | 48 ------------------------------------------------
1 files changed, 48 deletions(-)
Index: llvm-www/ProjectsWithLLVM/index.html
diff -u llvm-www/ProjectsWithLLVM/index.html:1.51 llvm-www/ProjectsWithLLVM/index.html:1.52
--- llvm-www/ProjectsWithLLVM/index.html:1.51 Wed Sep 30 01:25:42 2009
+++ llvm-www/ProjectsWithLLVM/index.html Tue Oct 13 11:24:04 2009
@@ -57,7 +57,6 @@
The XPS project's purpose is to making programming computers easier by
-raising the level of abstraction in programming languages beyond the current
-practice. By using XML as a means for extensibility, XPS will support both
-meta-programming and domain engineering. In particular, it will make the
-creation of new Domain-Specific Languages very easy. By moving the programming
-abstraction into to the problem domain, the "impedance mis-match" between the
-problem domain and the solution domain is all but eliminated.
-
-
XPS combines an XML-based programming language, XPL, with a robust virtual
-machine making it easier to develop applications by hiding all the "computer
-science" and increasing the level of abstraction without losing performance.
-True to its name, XPL is highly extensible. It permits extension of
-both the programming language and the virtual machine with relative ease.
-Somewhat counter-intuitively, XPL is not a particularly programmer friendly
-language. It is designed to be fast, efficient, and easily compilable. It is
-expected that higher level (e.g. domain specific) languages will be designed
-that translate into XPL. These facilities support meta-programming and domain
-engineering so that software can be written using domain-specific
-vocabularies. The goal is to make it possible for the lay person to program
-computers without having to learn complicated programming languages or
-understand the tenets of computer science.
-
-
Currently, XPS is under development. It has just completed its 0.2.0 release
-which includes a basic XPL compiler that can reproduce its XPL input. The next
-release, 0.3.0 (Summer 2005) will compile XPL to executable code via LLVM's
-facilities. The decision to use LLVM was made in November, 2003 as it provides
-a much simpler and more modern compiler infrastructure than the other open
-source alternatives. Using LLVM for the "back end" of XPS will accelerate the
-development of XPS because many of the compilation and execution details are
-taken care of by LLVM.
-
-
Further information about XPS can be obtained at
-http://x-p-s.org/.
From dpatel at apple.com Tue Oct 13 11:32:09 2009
From: dpatel at apple.com (Devang Patel)
Date: Tue, 13 Oct 2009 16:32:09 -0000
Subject: [llvm-commits] [llvm] r83975 -
/llvm/trunk/test/FrontendObjC/2009-08-17-DebugInfo.m
Message-ID: <200910131632.n9DGW9aT009042@zion.cs.uiuc.edu>
Author: dpatel
Date: Tue Oct 13 11:32:09 2009
New Revision: 83975
URL: http://llvm.org/viewvc/llvm-project?rev=83975&view=rev
Log:
Disable this test for now.
Modified:
llvm/trunk/test/FrontendObjC/2009-08-17-DebugInfo.m
Modified: llvm/trunk/test/FrontendObjC/2009-08-17-DebugInfo.m
URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/test/FrontendObjC/2009-08-17-DebugInfo.m?rev=83975&r1=83974&r2=83975&view=diff
==============================================================================
--- llvm/trunk/test/FrontendObjC/2009-08-17-DebugInfo.m (original)
+++ llvm/trunk/test/FrontendObjC/2009-08-17-DebugInfo.m Tue Oct 13 11:32:09 2009
@@ -6,7 +6,6 @@
// RUN: echo {break randomFunc\n} > %t.in
// RUN: gdb -q -batch -n -x %t.in %t.exe | tee %t.out | \
// RUN: grep {Breakpoint 1 at 0x.*: file 2009-08-17-DebugInfo.m, line 21}
-// XTARGET: darwin
// XFAIL: *
@interface MyClass
{
From resistor at mac.com Tue Oct 13 11:59:21 2009
From: resistor at mac.com (Owen Anderson)
Date: Tue, 13 Oct 2009 09:59:21 -0700
Subject: [llvm-commits] [llvm] r83959 - in /llvm/trunk:
lib/Analysis/BasicAliasAnalysis.cpp
test/Analysis/BasicAA/2009-10-13-AtomicModRef.ll
In-Reply-To: <200910130748.n9D7mdF0014001@zion.cs.uiuc.edu>
References: <200910130748.n9D7mdF0014001@zion.cs.uiuc.edu>
Message-ID:
Nick,
This shouldn't be necessary. Duncan and I did the same things back in
r63900 andr64551.
--Owen
On Oct 13, 2009, at 12:48 AM, Nick Lewycky wrote:
> Author: nicholas
> Date: Tue Oct 13 02:48:38 2009
> New Revision: 83959
>
> URL: http://llvm.org/viewvc/llvm-project?rev=83959&view=rev
> Log:
> Teach BasicAA a little something about the atomic intrinsics: they
> can only
> modify through the pointer they're given.
>
> Added:
> llvm/trunk/test/Analysis/BasicAA/2009-10-13-AtomicModRef.ll
> Modified:
> llvm/trunk/lib/Analysis/BasicAliasAnalysis.cpp
>
> Modified: llvm/trunk/lib/Analysis/BasicAliasAnalysis.cpp
> URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/lib/Analysis/BasicAliasAnalysis.cpp?rev=83959&r1=83958&r2=83959&view=diff
>
> =
> =
> =
> =
> =
> =
> =
> =
> ======================================================================
> --- llvm/trunk/lib/Analysis/BasicAliasAnalysis.cpp (original)
> +++ llvm/trunk/lib/Analysis/BasicAliasAnalysis.cpp Tue Oct 13
> 02:48:38 2009
> @@ -284,6 +284,27 @@
> if (!passedAsArg)
> return NoModRef;
> }
> +
> + if (IntrinsicInst *II = dyn_cast
> (CS.getInstruction())) {
> + switch (II->getIntrinsicID()) {
> + default: break;
> + case Intrinsic::atomic_cmp_swap:
> + case Intrinsic::atomic_swap:
> + case Intrinsic::atomic_load_add:
> + case Intrinsic::atomic_load_sub:
> + case Intrinsic::atomic_load_and:
> + case Intrinsic::atomic_load_nand:
> + case Intrinsic::atomic_load_or:
> + case Intrinsic::atomic_load_xor:
> + case Intrinsic::atomic_load_max:
> + case Intrinsic::atomic_load_min:
> + case Intrinsic::atomic_load_umax:
> + case Intrinsic::atomic_load_umin:
> + if (alias(II->getOperand(1), Size, P, Size) == NoAlias)
> + return NoModRef;
> + break;
> + }
> + }
> }
>
> // The AliasAnalysis base class has some smarts, lets use them.
>
> Added: llvm/trunk/test/Analysis/BasicAA/2009-10-13-AtomicModRef.ll
> URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/test/Analysis/BasicAA/2009-10-13-AtomicModRef.ll?rev=83959&view=auto
>
> =
> =
> =
> =
> =
> =
> =
> =
> ======================================================================
> --- llvm/trunk/test/Analysis/BasicAA/2009-10-13-AtomicModRef.ll
> (added)
> +++ llvm/trunk/test/Analysis/BasicAA/2009-10-13-AtomicModRef.ll Tue
> Oct 13 02:48:38 2009
> @@ -0,0 +1,16 @@
> +; RUN: opt -gvn -S < %s | FileCheck %s
> +
> +declare i8 @llvm.atomic.load.add.i8.p0i8(i8*, i8)
> +
> +define void @foo(i8* %ptr) {
> + %P = getelementptr i8* %ptr, i32 0
> + %Q = getelementptr i8* %ptr, i32 1
> +; CHECK: getelementptr
> + %X = load i8* %P
> +; CHECK: = load
> + %Y = call i8 @llvm.atomic.load.add.i8.p0i8(i8* %Q, i8 1)
> + %Z = load i8* %P
> +; CHECK-NOT: = load
> + ret void
> +; CHECK: ret void
> +}
>
>
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2620 bytes
Desc: not available
Url : http://lists.cs.uiuc.edu/pipermail/llvm-commits/attachments/20091013/6918eef0/attachment.bin
From dpatel at apple.com Tue Oct 13 12:00:54 2009
From: dpatel at apple.com (Devang Patel)
Date: Tue, 13 Oct 2009 17:00:54 -0000
Subject: [llvm-commits] [llvm] r83977 - in /llvm/trunk:
include/llvm/Metadata.h lib/VMCore/Metadata.cpp lib/VMCore/Value.cpp
Message-ID: <200910131700.n9DH0sGT010067@zion.cs.uiuc.edu>
Author: dpatel
Date: Tue Oct 13 12:00:54 2009
New Revision: 83977
URL: http://llvm.org/viewvc/llvm-project?rev=83977&view=rev
Log:
Copy metadata when value is RAUW'd. It is debatable whether this is the right approach for custom metadata data in general. However, right now the only custom data user, "dbg", expects this behavior while FE is constructing llvm IR with debug info.
Modified:
llvm/trunk/include/llvm/Metadata.h
llvm/trunk/lib/VMCore/Metadata.cpp
llvm/trunk/lib/VMCore/Value.cpp
Modified: llvm/trunk/include/llvm/Metadata.h
URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/include/llvm/Metadata.h?rev=83977&r1=83976&r2=83977&view=diff
==============================================================================
--- llvm/trunk/include/llvm/Metadata.h (original)
+++ llvm/trunk/include/llvm/Metadata.h Tue Oct 13 12:00:54 2009
@@ -361,6 +361,7 @@
void ValueIsDeleted(const Instruction *Inst) {
removeMDs(Inst);
}
+ void ValueIsRAUWd(Value *V1, Value *V2);
/// ValueIsCloned - This handler is used to update metadata store
/// when In1 is cloned to create In2.
Modified: llvm/trunk/lib/VMCore/Metadata.cpp
URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/lib/VMCore/Metadata.cpp?rev=83977&r1=83976&r2=83977&view=diff
==============================================================================
--- llvm/trunk/lib/VMCore/Metadata.cpp (original)
+++ llvm/trunk/lib/VMCore/Metadata.cpp Tue Oct 13 12:00:54 2009
@@ -404,3 +404,15 @@
if (MDNode *MD = dyn_cast_or_null(I->second))
addMD(I->first, MD, In2);
}
+
+/// ValueIsRAUWd - This handler is used when V1's all uses are replaced by
+/// V2.
+void MetadataContext::ValueIsRAUWd(Value *V1, Value *V2) {
+ Instruction *I1 = dyn_cast(V1);
+ Instruction *I2 = dyn_cast(V2);
+ if (!I1 || !I2)
+ return;
+
+ // FIXME : Give custom handlers a chance to override this.
+ ValueIsCloned(I1, I2);
+}
Modified: llvm/trunk/lib/VMCore/Value.cpp
URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/lib/VMCore/Value.cpp?rev=83977&r1=83976&r2=83977&view=diff
==============================================================================
--- llvm/trunk/lib/VMCore/Value.cpp (original)
+++ llvm/trunk/lib/VMCore/Value.cpp Tue Oct 13 12:00:54 2009
@@ -309,6 +309,10 @@
// Notify all ValueHandles (if present) that this value is going away.
if (HasValueHandle)
ValueHandleBase::ValueIsRAUWd(this, New);
+ if (HasMetadata) {
+ LLVMContext &Context = getContext();
+ Context.pImpl->TheMetadata.ValueIsRAUWd(this, New);
+ }
while (!use_empty()) {
Use &U = *UseList;
From jyasskin at google.com Tue Oct 13 12:16:06 2009
From: jyasskin at google.com (Jeffrey Yasskin)
Date: Tue, 13 Oct 2009 10:16:06 -0700
Subject: [llvm-commits] [PATCH] Make ExecutionEngine automatically
remove global mappings on GlobalValue destruction
In-Reply-To: <6F95F744-B216-4EB0-9A6C-14ECF07FFB5E@apple.com>
References: <0016363b7bded75fc30475c6559a@google.com>
<6F95F744-B216-4EB0-9A6C-14ECF07FFB5E@apple.com>
Message-ID:
Done and committing. Thanks for the review!
On Tue, Oct 13, 2009 at 2:01 AM, Evan Cheng wrote:
> Looks good to me. I'd preferred if "state" can be renamed to something
> like EEState though.
>
> Evan
>
> On Oct 12, 2009, at 5:43 PM, jyasskin at gmail.com wrote:
>
>> Reviewers: ,
>>
>> Message:
>> http://codereview.appspot.com/download/issue129074_5.diff
>>
>> This doesn't make the ExecutionEngine do everything perfectly on
>> GlobalValue destruction (stubs still crash and machine code still
>> leaks), but it's progress.
>>
>>
>>
>> Please review this at http://codereview.appspot.com/129074
>>
>> Affected files:
>> ? M include/llvm/ExecutionEngine/ExecutionEngine.h
>> ? M lib/ExecutionEngine/ExecutionEngine.cpp
>> ? M unittests/ExecutionEngine/ExecutionEngineTest.cpp
>>
>>
>> _______________________________________________
>> llvm-commits mailing list
>> llvm-commits at cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
>
From devang.patel at gmail.com Tue Oct 13 12:16:17 2009
From: devang.patel at gmail.com (Devang Patel)
Date: Tue, 13 Oct 2009 10:16:17 -0700
Subject: [llvm-commits] [PATCH] Preserve DebugInfo during LICM
In-Reply-To: <4AD22FBF.3060607@gmail.com>
References: <4ACDAF90.1040202@gmail.com>
<4AD22FBF.3060607@gmail.com>
Message-ID: <352a1fb20910131016g41abc9e0v3ff54f001324075c@mail.gmail.com>
2009/10/11 T?r?k Edwin :
>>> I think that we'd need another TEST.dbgquality that tests whether each
>>> basicblock has at least one stoppoint (if original did),
>>> and also outputs how many instructions have a stoppoint in same BB, how
>>> many have a stoppoint
>>> foundable by findStopPointInst, and how many don't have at all. The test
>>> would pass if each BB has at least one stoppoint,
>>
>> I'm not sure what the right approach is here. ?When stoppoints move to
>> being on the instructions, we won't really need this.
>
> We'd need something else: ?check that each insn has a debug info, some
> optimizers may create new instructions and forget
> to set debug info.
>
> But you're right, there is no point working on this now, since the debug
> info is about to undergo a major change.
>
Now, debug info (location info) is attached to an instruction. There
is a way to check this.
MetadataContext &TheMetadata = ...getContext().getMetadata();
unsigned MDDbgKind = TheMetadata.getMDKind("dbg");
if (MDNode *Dbg = TheMetadata.getMD(MDDbgKind, I)) {
Here Dbg is non-null if debug info is attached with instruction I.
-
Devang
From edwintorok at gmail.com Tue Oct 13 12:26:26 2009
From: edwintorok at gmail.com (=?ISO-8859-1?Q?T=F6r=F6k_Edwin?=)
Date: Tue, 13 Oct 2009 20:26:26 +0300
Subject: [llvm-commits] [PATCH] Preserve DebugInfo during LICM
In-Reply-To: <352a1fb20910131016g41abc9e0v3ff54f001324075c@mail.gmail.com>
References: <4ACDAF90.1040202@gmail.com>
<4AD22FBF.3060607@gmail.com>
<352a1fb20910131016g41abc9e0v3ff54f001324075c@mail.gmail.com>
Message-ID: <4AD4B842.10703@gmail.com>
On 2009-10-13 20:16, Devang Patel wrote:
> 2009/10/11 T?r?k Edwin :
>
>>>> I think that we'd need another TEST.dbgquality that tests whether each
>>>> basicblock has at least one stoppoint (if original did),
>>>> and also outputs how many instructions have a stoppoint in same BB, how
>>>> many have a stoppoint
>>>> foundable by findStopPointInst, and how many don't have at all. The test
>>>> would pass if each BB has at least one stoppoint,
>>>>
>>> I'm not sure what the right approach is here. When stoppoints move to
>>> being on the instructions, we won't really need this.
>>>
>> We'd need something else: check that each insn has a debug info, some
>> optimizers may create new instructions and forget
>> to set debug info.
>>
>> But you're right, there is no point working on this now, since the debug
>> info is about to undergo a major change.
>>
>>
>
> Now, debug info (location info) is attached to an instruction. There
> is a way to check this.
>
> MetadataContext &TheMetadata = ...getContext().getMetadata();
> unsigned MDDbgKind = TheMetadata.getMDKind("dbg");
> if (MDNode *Dbg = TheMetadata.getMD(MDDbgKind, I)) {
>
Maybe I should update findStopPoint to return dbg metadata instead of a
stoppoint, if stoppoints are going away?
If stoppoints are going away please let me know so I can update
Analysis/DbgInfoPrinter.cpp too.
> Here Dbg is non-null if debug info is attached with instruction I.
>
Does llvm-gcc and clang support emitting dbgmetadata on instructions?
If yes I'll start working on something that measures quality of dbginfo
in the testsuite, and maybe do some checks too.
Also does this move to metadata on instructions fix the
linker/inliner(?) bug where the line number was greater than the total
lines in the file?
And the bug that you can't link together multiple files with debug info
due to multiple main compilation units?
Best regards,
--Edwin
From bob.wilson at apple.com Tue Oct 13 12:29:13 2009
From: bob.wilson at apple.com (Bob Wilson)
Date: Tue, 13 Oct 2009 17:29:13 -0000
Subject: [llvm-commits] [llvm] r83982 -
/llvm/trunk/lib/Target/ARM/ARMConstantIslandPass.cpp
Message-ID: <200910131729.n9DHTDc5011331@zion.cs.uiuc.edu>
Author: bwilson
Date: Tue Oct 13 12:29:13 2009
New Revision: 83982
URL: http://llvm.org/viewvc/llvm-project?rev=83982&view=rev
Log:
Fix regression introduced by r83894.
Modified:
llvm/trunk/lib/Target/ARM/ARMConstantIslandPass.cpp
Modified: llvm/trunk/lib/Target/ARM/ARMConstantIslandPass.cpp
URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/lib/Target/ARM/ARMConstantIslandPass.cpp?rev=83982&r1=83981&r2=83982&view=diff
==============================================================================
--- llvm/trunk/lib/Target/ARM/ARMConstantIslandPass.cpp (original)
+++ llvm/trunk/lib/Target/ARM/ARMConstantIslandPass.cpp Tue Oct 13 12:29:13 2009
@@ -933,13 +933,14 @@
///
MachineBasicBlock *ARMConstantIslands::AcceptWater(water_iterator IP) {
DEBUG(errs() << "found water in range\n");
+ MachineBasicBlock *WaterBB = *IP;
// Remove the original WaterList entry; we want subsequent
// insertions in this vicinity to go after the one we're
// about to insert. This considerably reduces the number
// of times we have to move the same CPE more than once.
WaterList.erase(IP);
// CPE goes before following block (NewMBB).
- return next(MachineFunction::iterator(*IP));
+ return next(MachineFunction::iterator(WaterBB));
}
/// LookForWater - look for an existing entry in the WaterList in which
From clattner at apple.com Tue Oct 13 12:34:09 2009
From: clattner at apple.com (Chris Lattner)
Date: Tue, 13 Oct 2009 10:34:09 -0700
Subject: [llvm-commits] [llvm] r83959 - in /llvm/trunk:
lib/Analysis/BasicAliasAnalysis.cpp
test/Analysis/BasicAA/2009-10-13-AtomicModRef.ll
In-Reply-To: <200910130748.n9D7mdF0014001@zion.cs.uiuc.edu>
References: <200910130748.n9D7mdF0014001@zion.cs.uiuc.edu>
Message-ID: <33FD0425-F50F-48AE-B06B-9CEC9ECC9BF9@apple.com>
On Oct 13, 2009, at 12:48 AM, Nick Lewycky wrote:
> URL: http://llvm.org/viewvc/llvm-project?rev=83959&view=rev
> Log:
> Teach BasicAA a little something about the atomic intrinsics: they
> can only
> modify through the pointer they're given.
Thanks Nick,
> +
> +define void @foo(i8* %ptr) {
> + %P = getelementptr i8* %ptr, i32 0
> + %Q = getelementptr i8* %ptr, i32 1
> +; CHECK: getelementptr
> + %X = load i8* %P
> +; CHECK: = load
> + %Y = call i8 @llvm.atomic.load.add.i8.p0i8(i8* %Q, i8 1)
> + %Z = load i8* %P
> +; CHECK-NOT: = load
> + ret void
> +; CHECK: ret void
> +}
Please add some uses of the loads: do: "ret sub X,Z", and FileCheck
that GVN+instcombine turn it into "ret i32 0"
-Chris
From bob.wilson at apple.com Tue Oct 13 12:35:30 2009
From: bob.wilson at apple.com (Bob Wilson)
Date: Tue, 13 Oct 2009 17:35:30 -0000
Subject: [llvm-commits] [llvm] r83983 -
/llvm/trunk/lib/Target/ARM/ARMInstrInfo.td
Message-ID: <200910131735.n9DHZVfS011591@zion.cs.uiuc.edu>
Author: bwilson
Date: Tue Oct 13 12:35:30 2009
New Revision: 83983
URL: http://llvm.org/viewvc/llvm-project?rev=83983&view=rev
Log:
Add some ARM instruction encoding bits.
Patch by Johnny Chen.
Modified:
llvm/trunk/lib/Target/ARM/ARMInstrInfo.td
Modified: llvm/trunk/lib/Target/ARM/ARMInstrInfo.td
URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/lib/Target/ARM/ARMInstrInfo.td?rev=83983&r1=83982&r2=83983&view=diff
==============================================================================
--- llvm/trunk/lib/Target/ARM/ARMInstrInfo.td (original)
+++ llvm/trunk/lib/Target/ARM/ARMInstrInfo.td Tue Oct 13 12:35:30 2009
@@ -416,17 +416,20 @@
def ri : AI1 {
+ let Inst{20} = 1;
let Inst{25} = 1;
}
def rr : AI1 {
+ let Inst{20} = 1;
let Inst{25} = 0;
let isCommutable = Commutable;
}
def rs : AI1 {
+ let Inst{20} = 1;
let Inst{25} = 0;
}
}
@@ -934,6 +937,7 @@
"movw", " $dst, $src",
[(set GPR:$dst, imm0_65535:$src)]>,
Requires<[IsARM, HasV6T2]> {
+ let Inst{20} = 0;
let Inst{25} = 1;
}
@@ -945,6 +949,7 @@
(or (and GPR:$src, 0xffff),
lo16AllZero:$imm))]>, UnaryDP,
Requires<[IsARM, HasV6T2]> {
+ let Inst{20} = 0;
let Inst{25} = 1;
}
From dpatel at apple.com Tue Oct 13 12:35:35 2009
From: dpatel at apple.com (Devang Patel)
Date: Tue, 13 Oct 2009 17:35:35 -0000
Subject: [llvm-commits] [llvm] r83984 -
/llvm/trunk/lib/Analysis/DebugInfo.cpp
Message-ID: <200910131735.n9DHZZg2011605@zion.cs.uiuc.edu>
Author: dpatel
Date: Tue Oct 13 12:35:35 2009
New Revision: 83984
URL: http://llvm.org/viewvc/llvm-project?rev=83984&view=rev
Log:
"there is not any instruction with attached debug info in this module" does not mean "there is no debug info in this module". :)
Modified:
llvm/trunk/lib/Analysis/DebugInfo.cpp
Modified: llvm/trunk/lib/Analysis/DebugInfo.cpp
URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/lib/Analysis/DebugInfo.cpp?rev=83984&r1=83983&r2=83984&view=diff
==============================================================================
--- llvm/trunk/lib/Analysis/DebugInfo.cpp (original)
+++ llvm/trunk/lib/Analysis/DebugInfo.cpp Tue Oct 13 12:35:35 2009
@@ -969,8 +969,6 @@
#ifdef ATTACH_DEBUG_INFO_TO_AN_INSN
MetadataContext &TheMetadata = M.getContext().getMetadata();
unsigned MDDbgKind = TheMetadata.getMDKind("dbg");
- if (!MDDbgKind)
- return;
#endif
for (Module::iterator I = M.begin(), E = M.end(); I != E; ++I)
for (Function::iterator FI = (*I).begin(), FE = (*I).end(); FI != FE; ++FI)
@@ -987,15 +985,17 @@
else if (DbgDeclareInst *DDI = dyn_cast(BI))
processDeclare(DDI);
#ifdef ATTACH_DEBUG_INFO_TO_AN_INSN
- else if (MDNode *L = TheMetadata.getMD(MDDbgKind, BI)) {
- DILocation Loc(L);
- DIScope S(Loc.getScope().getNode());
- if (S.isCompileUnit())
- addCompileUnit(DICompileUnit(S.getNode()));
- else if (S.isSubprogram())
- processSubprogram(DISubprogram(S.getNode()));
- else if (S.isLexicalBlock())
- processLexicalBlock(DILexicalBlock(S.getNode()));
+ else if (MDDbgKind) {
+ if (MDNode *L = TheMetadata.getMD(MDDbgKind, BI)) {
+ DILocation Loc(L);
+ DIScope S(Loc.getScope().getNode());
+ if (S.isCompileUnit())
+ addCompileUnit(DICompileUnit(S.getNode()));
+ else if (S.isSubprogram())
+ processSubprogram(DISubprogram(S.getNode()));
+ else if (S.isLexicalBlock())
+ processLexicalBlock(DILexicalBlock(S.getNode()));
+ }
}
#endif
}
From devang.patel at gmail.com Tue Oct 13 12:40:01 2009
From: devang.patel at gmail.com (Devang Patel)
Date: Tue, 13 Oct 2009 10:40:01 -0700
Subject: [llvm-commits] [PATCH] Preserve DebugInfo during LICM
In-Reply-To: <4AD4B842.10703@gmail.com>
References: <4ACDAF90.1040202@gmail.com>
<4AD22FBF.3060607@gmail.com>
<352a1fb20910131016g41abc9e0v3ff54f001324075c@mail.gmail.com>
<4AD4B842.10703@gmail.com>
Message-ID: <352a1fb20910131040k40fd72eag829f499a6a04f0e4@mail.gmail.com>
2009/10/13 T?r?k Edwin :
> On 2009-10-13 20:16, Devang Patel wrote:
>> 2009/10/11 T?r?k Edwin :
>>
>>>>> I think that we'd need another TEST.dbgquality that tests whether each
>>>>> basicblock has at least one stoppoint (if original did),
>>>>> and also outputs how many instructions have a stoppoint in same BB, how
>>>>> many have a stoppoint
>>>>> foundable by findStopPointInst, and how many don't have at all. The test
>>>>> would pass if each BB has at least one stoppoint,
>>>>>
>>>> I'm not sure what the right approach is here. ?When stoppoints move to
>>>> being on the instructions, we won't really need this.
>>>>
>>> We'd need something else: ?check that each insn has a debug info, some
>>> optimizers may create new instructions and forget
>>> to set debug info.
>>>
>>> But you're right, there is no point working on this now, since the debug
>>> info is about to undergo a major change.
>>>
>>>
>>
>> Now, debug info (location info) is attached to an instruction. There
>> is a way to check this.
>>
>> ? MetadataContext &TheMetadata = ...getContext().getMetadata();
>> ? unsigned MDDbgKind = TheMetadata.getMDKind("dbg");
>> ? if (MDNode *Dbg = TheMetadata.getMD(MDDbgKind, I)) {
>>
>
> Maybe I should update findStopPoint to return dbg metadata instead of a
> stoppoint, if stoppoints are going away?
Eventually yes. I'll wait for things to settle down before completely
removing this.
>
> If stoppoints are going away please let me know so I can update
> Analysis/DbgInfoPrinter.cpp too.
>> Here Dbg is non-null if debug info is attached with instruction I.
>>
>
> Does llvm-gcc and clang support emitting dbgmetadata on instructions?
Yes, I flipped the switch yesterday.
> If yes I'll start working on something that measures quality of dbginfo
> in the testsuite, and maybe do some checks too.
That'd be very useful.
> Also does this move to metadata on instructions fix the
> linker/inliner(?) bug where the line number was greater than the total
> lines in the file?
Not yet.
> And the bug that you can't link together multiple files with debug info
> due to multiple main compilation units?
Not yet.
-
Devang
From sabre at nondot.org Tue Oct 13 12:39:30 2009
From: sabre at nondot.org (Chris Lattner)
Date: Tue, 13 Oct 2009 17:39:30 -0000
Subject: [llvm-commits] [llvm] r83985 -
/llvm/trunk/test/Analysis/BasicAA/cas.ll
Message-ID: <200910131739.n9DHdUp0011769@zion.cs.uiuc.edu>
Author: lattner
Date: Tue Oct 13 12:39:29 2009
New Revision: 83985
URL: http://llvm.org/viewvc/llvm-project?rev=83985&view=rev
Log:
don't use dead loads as tests.
Modified:
llvm/trunk/test/Analysis/BasicAA/cas.ll
Modified: llvm/trunk/test/Analysis/BasicAA/cas.ll
URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/test/Analysis/BasicAA/cas.ll?rev=83985&r1=83984&r2=83985&view=diff
==============================================================================
--- llvm/trunk/test/Analysis/BasicAA/cas.ll (original)
+++ llvm/trunk/test/Analysis/BasicAA/cas.ll Tue Oct 13 12:39:29 2009
@@ -1,4 +1,4 @@
-; RUN: opt < %s -basicaa -gvn -S | grep load | count 1
+; RUN: opt < %s -basicaa -gvn -instcombine -S | grep {ret i32 0}
@flag0 = internal global i32 zeroinitializer
@turn = internal global i32 zeroinitializer
@@ -6,9 +6,10 @@
define i32 @main() {
%a = load i32* @flag0
- %b = tail call i32 @llvm.atomic.swap.i32.p0i32(i32* @turn, i32 1)
+ %b = tail call i32 @llvm.atomic.swap.i32.p0i32(i32* @turn, i32 1)
%c = load i32* @flag0
- ret i32 %c
+ %d = sub i32 %a, %c
+ ret i32 %d
}
declare i32 @llvm.atomic.swap.i32.p0i32(i32*, i32) nounwind
\ No newline at end of file
From jyasskin at google.com Tue Oct 13 12:42:08 2009
From: jyasskin at google.com (Jeffrey Yasskin)
Date: Tue, 13 Oct 2009 17:42:08 -0000
Subject: [llvm-commits] [llvm] r83987 - in /llvm/trunk:
include/llvm/ExecutionEngine/ExecutionEngine.h
lib/ExecutionEngine/ExecutionEngine.cpp
unittests/ExecutionEngine/ExecutionEngineTest.cpp
Message-ID: <200910131742.n9DHg9cD011982@zion.cs.uiuc.edu>
Author: jyasskin
Date: Tue Oct 13 12:42:08 2009
New Revision: 83987
URL: http://llvm.org/viewvc/llvm-project?rev=83987&view=rev
Log:
Make the ExecutionEngine automatically remove global mappings on when their
GlobalValue is destroyed. Function destruction still leaks machine code and
can crash on leaked stubs, but this is some progress.
Modified:
llvm/trunk/include/llvm/ExecutionEngine/ExecutionEngine.h
llvm/trunk/lib/ExecutionEngine/ExecutionEngine.cpp
llvm/trunk/unittests/ExecutionEngine/ExecutionEngineTest.cpp
Modified: llvm/trunk/include/llvm/ExecutionEngine/ExecutionEngine.h
URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/include/llvm/ExecutionEngine/ExecutionEngine.h?rev=83987&r1=83986&r2=83987&view=diff
==============================================================================
--- llvm/trunk/include/llvm/ExecutionEngine/ExecutionEngine.h (original)
+++ llvm/trunk/include/llvm/ExecutionEngine/ExecutionEngine.h Tue Oct 13 12:42:08 2009
@@ -19,6 +19,7 @@
#include
+IcedTea provides a
+harness to build OpenJDK using only free software build tools and to provide
+replacements for the not-yet free parts of OpenJDK. One of the extensions that
+IcedTea provides is a new JIT compiler named Shark which uses LLVM
+to provide native code generation without introducing processor-dependent
+code.
+
This document contains the release notes for the LLVM Compiler
-Infrastructure, release 2.6. Here we describe the status of LLVM, including
-major improvements from the previous release and significant known problems.
-All LLVM releases may be downloaded from the LLVM releases web site.
-
-
For more information about LLVM, including information about the latest
-release, please check out the main LLVM
-web site. If you have questions or comments, the LLVM Developer's Mailing
-List is a good place to send them.
-
-
Note that if you are reading this file from a Subversion checkout or the
-main LLVM web page, this document applies to the next release, not the
-current one. To see the release notes for a specific release, please see the
-releases page.
-The LLVM 2.6 distribution currently consists of code from the core LLVM
-repository (which roughly includes the LLVM optimizers, code generators
-and supporting tools), the Clang repository and the llvm-gcc repository. In
-addition to this code, the LLVM Project includes other sub-projects that are in
-development. Here we include updates on these subprojects.
-
The Clang project is an effort to build
-a set of new 'LLVM native' front-end technologies for the C family of languages.
-LLVM 2.6 is the first release to officially include Clang, and it provides a
-production quality C and Objective-C compiler. If you are interested in fast compiles and
-good diagnostics, we
-encourage you to try it out. Clang currently compiles typical Objective-C code
-3x faster than GCC and compiles C code about 30% faster than GCC at -O0 -g
-(which is when the most pressure is on the frontend).
-
-
In addition to supporting these languages, C++ support is also well under way, and mainline
-Clang is able to parse the libstdc++ 4.2 headers and even codegen simple apps.
-If you are interested in Clang C++ support or any other Clang feature, we
-strongly encourage you to get involved on the Clang front-end mailing
-list.
-
-
In the LLVM 2.6 time-frame, the Clang team has made many improvements:
-
-
-
C and Objective-C support are now considered production quality.
-
AuroraUX, FreeBSD and OpenBSD are now supported.
-
Most of Objective-C 2.0 is now supported with the GNU runtime.
-
Many many bugs are fixed and lots of features have been added.
Previously announced in the 2.4 and 2.5 LLVM releases, the Clang project also
-includes an early stage static source code analysis tool for automatically finding bugs
-in C and Objective-C programs. The tool performs checks to find
-bugs that occur on a specific path within a program.
-
-
In the LLVM 2.6 time-frame, the analyzer core has undergone several important
-improvements and cleanups and now includes a new Checker interface that
-is intended to eventually serve as a basis for domain-specific checks. Further,
-in addition to generating HTML files for reporting analysis results, the
-analyzer can now also emit bug reports in a structured XML format that is
-intended to be easily readable by other programs.
-
-
The set of checks performed by the static analyzer continues to expand, and
-future plans for the tool include full source-level inter-procedural analysis
-and deeper checks such as buffer overrun detection. There are many opportunities
-to extend and enhance the static analyzer, and anyone interested in working on
-this project is encouraged to get involved!
-The VMKit project is an implementation of
-a JVM and a CLI Virtual Machine (Microsoft .NET is an
-implementation of the CLI) using LLVM for static and just-in-time
-compilation.
-
-
-VMKit version 0.26 builds with LLVM 2.6 and you can find it on its
-web page. The release includes
-bug fixes, cleanup and new features. The major changes are:
-
-
-
-
A new llcj tool to generate shared libraries or executables of Java
- files.
-
Cooperative garbage collection.
-
Fast subtype checking (paper from Click et al [JGI'02]).
-
Implementation of a two-word header for Java objects instead of the original
- three-word header.
-
Better Java specification-compliance: division by zero checks, stack
- overflow checks, finalization and references support.
-The new LLVM compiler-rt project
-is a simple library that provides an implementation of the low-level
-target-specific hooks required by code generation and other runtime components.
-For example, when compiling for a 32-bit target, converting a double to a 64-bit
-unsigned integer is compiled into a runtime call to the "__fixunsdfdi"
-function. The compiler-rt library provides highly optimized implementations of
-this and other low-level routines (some are 3x faster than the equivalent
-libgcc routines).
-
-
-All of the code in the compiler-rt project is available under the standard LLVM
-License, a "BSD-style" license.
-The new LLVM KLEE project is a symbolic
-execution framework for programs in LLVM bitcode form. KLEE tries to
-symbolically evaluate "all" paths through the application and records state
-transitions that lead to fault states. This allows it to construct testcases
-that lead to faults and can even be used to verify algorithms. For more
-details, please see the OSDI 2008 paper about
-KLEE.
-The goal of DragonEgg is to make
-gcc-4.5 act like llvm-gcc without requiring any gcc modifications whatsoever.
-DragonEgg is a shared library (llvm.so)
-that is loaded by gcc at runtime. It uses the new gcc plugin architecture to
-disable the GCC optimizers and code generators, and schedule the LLVM optimizers
-and code generators (or direct output of LLVM IR) instead. Currently only Linux
-and Darwin are supported, and only on x86-32 and x86-64. It should be easy to
-add additional unix-like architectures and other processor families. In theory
-it should be possible to use DragonEgg
-with any language supported by gcc, however only C and Fortran work well for the
-moment. Ada and C++ work to some extent, while Java, Obj-C and Obj-C++ are so
-far entirely untested. Since gcc-4.5 has not yet been released, neither has
-DragonEgg. To build
-DragonEgg you will need to check out the
-development versions of gcc,
-llvm and
-DragonEgg from their respective
-subversion repositories, and follow the instructions in the
-DragonEgg README.
-
-The LLVM Machine Code (MC) Toolkit project is a (very early) effort to build
-better tools for dealing with machine code, object file formats, etc. The idea
-is to be able to generate most of the target specific details of assemblers and
-disassemblers from existing LLVM target .td files (with suitable enhancements),
-and to build infrastructure for reading and writing common object file formats.
-One of the first deliverables is to build a full assembler and integrate it into
-the compiler, which is predicted to substantially reduce compile time in some
-scenarios.
-
-
-
In the LLVM 2.6 timeframe, the MC framework has grown to the point where it
-can reliably parse and pretty print (with some encoding information) a
-darwin/x86 .s file successfully, and has the very early phases of a Mach-O
-assembler in progress. Beyond the MC framework itself, major refactoring of the
-LLVM code generator has started. The idea is to make the code generator reason
-about the code it is producing in a much more semantic way, rather than a
-textual way. For example, the code generator now uses MCSection objects to
-represent section assignments, instead of text strings that print to .section
-directives.
-
-
MC is an early and ongoing project that will hopefully continue to lead to
-many improvements in the code generator and build infrastructure useful for many
-other situations.
-
An exciting aspect of LLVM is that it is used as an enabling technology for
- a lot of other language and tools projects. This section lists some of the
- projects that have already been updated to work with LLVM 2.6.
Rubinius is an environment
-for running Ruby code which strives to write as much of the core class
-implementation in Ruby as possible. Combined with a bytecode interpreting VM, it
-uses LLVM to optimize and compile ruby code down to machine code. Techniques
-such as type feedback, method inlining, and uncommon traps are all used to
-remove dynamism from ruby execution and increase performance.
-
-
Since LLVM 2.5, Rubinius has made several major leaps forward, implementing
-a counter based JIT, type feedback and speculative method inlining.
-
-MacRuby is an implementation of Ruby on top of
-core Mac OS X technologies, such as the Objective-C common runtime and garbage
-collector and the CoreFoundation framework. It is principally developed by
-Apple and aims at enabling the creation of full-fledged Mac OS X applications.
-
-
-
-MacRuby uses LLVM for optimization passes, JIT and AOT compilation of Ruby
-expressions. It also uses zero-cost DWARF exceptions to implement Ruby exception
-handling.
-Pure
-is an algebraic/functional programming language based on term rewriting.
-Programs are collections of equations which are used to evaluate expressions in
-a symbolic fashion. Pure offers dynamic typing, eager and lazy evaluation,
-lexical closures, a hygienic macro system (also based on term rewriting),
-built-in list and matrix support (including list and matrix comprehensions) and
-an easy-to-use C interface. The interpreter uses LLVM as a backend to
- JIT-compile Pure programs to fast native code.
-
-
Pure versions 0.31 and later have been tested and are known to work with
-LLVM 2.6 (and continue to work with older LLVM releases >= 2.3 as well).
-
-LDC is an implementation of
-the D Programming Language using the LLVM optimizer and code generator.
-The LDC project works great with the LLVM 2.6 release. General improvements in
-this
-cycle have included new inline asm constraint handling, better debug info
-support, general bug fixes and better x86-64 support. This has allowed
-some major improvements in LDC, getting it much closer to being as
-fully featured as the original DMD compiler from DigitalMars.
-
-Roadsend PHP (rphp) is an open
-source implementation of the PHP programming
-language that uses LLVM for its optimizer, JIT and static compiler. This is a
-reimplementation of an earlier project that is now based on LLVM.
-Unladen Swallow is a
-branch of Python intended to be fully
-compatible and significantly faster. It uses LLVM's optimization passes and JIT
-compiler.
-LLVM-Lua uses LLVM to add JIT
-and static compiling support to the Lua VM. Lua bytecode is analyzed to
-remove type checks, then LLVM is used to compile the bytecode down to machine
-code.
-IcedTea provides a
-harness to build OpenJDK using only free software build tools and to provide
-replacements for the not-yet free parts of OpenJDK. One of the extensions that
-IcedTea provides is a new JIT compiler named Shark which uses LLVM
-to provide native code generation without introducing processor-dependent
-code.
-
This release includes a huge number of bug fixes, performance tweaks and
-minor improvements. Some of the major improvements and new features are listed
-in this section.
-
Debug information now includes line numbers when optimizations are enabled.
- This allows statistical sampling tools like OProfile and Shark to map
- samples back to source lines.
-
LLVM now includes new experimental backends to support the MSP430, SystemZ
- and BlackFin architectures.
LLVM now supports doing optimization and code generation on multiple
- threads. Please see the LLVM
- Programmer's Manual for more information.
-
LLVM now has experimental support for embedded
- metadata in LLVM IR, though the implementation is not guaranteed to be
- final and the .bc file format may change in future releases. Debug info
- does not yet use this format in LLVM 2.6.
LLVM IR has several new features for better support of new targets and that
-expose new optimization opportunities:
-
-
-
The add, sub and mul
- instructions have been split into integer and floating point versions (like
- divide and remainder), introducing new fadd, fsub,
- and fmul instructions.
-
The add, sub and mul
- instructions now support optional "nsw" and "nuw" bits which indicate that
- the operation is guaranteed to not overflow (in the signed or
- unsigned case, respectively). This gives the optimizer more information and
- can be used for things like C signed integer values, which are undefined on
- overflow.
-
The sdiv instruction now supports an
- optional "exact" flag which indicates that the result of the division is
- guaranteed to have a remainder of zero. This is useful for optimizing pointer
- subtraction in C.
-
The getelementptr instruction now
- supports arbitrary integer index values for array/pointer indices. This
- allows for better code generation on 16-bit pointer targets like PIC16.
-
The getelementptr instruction now
- supports an "inbounds" optimization hint that tells the optimizer that the
- pointer is guaranteed to be within its allocated object.
-
LLVM now support a series of new linkage types for global values which allow
- for better optimization and new capabilities:
-
-
linkonce_odr and
- weak_odr have the same linkage
- semantics as the non-"odr" linkage types. The difference is that these
- linkage types indicate that all definitions of the specified function
- are guaranteed to have the same semantics. This allows inlining
- templates functions in C++ but not inlining weak functions in C,
- which previously both got the same linkage type.
-
available_externally
- is a new linkage type that gives the optimizer visibility into the
- definition of a function (allowing inlining and side effect analysis)
- but that does not cause code to be generated. This allows better
- optimization of "GNU inline" functions, extern templates, etc.
-
linker_private is a
- new linkage type (which is only useful on Mac OS X) that is used for
- some metadata generation and other obscure things.
-
-
Finally, target-specific intrinsics can now return multiple values, which
- is useful for modeling target operations with multiple results.
In addition to a large array of minor performance tweaks and bug fixes, this
-release includes a few major enhancements and additions to the optimizers:
-
-
-
-
The Scalar Replacement of Aggregates
- pass has many improvements that allow it to better promote vector unions,
- variables which are memset, and much more strange code that can happen to
- do bitfield accesses to register operations. An interesting change is that
- it now produces "unusual" integer sizes (like i1704) in some cases and lets
- other optimizers clean things up.
-
The Loop Strength Reduction pass now
- promotes small integer induction variables to 64-bit on 64-bit targets,
- which provides a major performance boost for much numerical code. It also
- promotes shorts to int on 32-bit hosts, etc. LSR now also analyzes pointer
- expressions (e.g. getelementptrs), as well as integers.
-
The GVN pass now eliminates partial
- redundancies of loads in simple cases.
-
The Inliner now reuses stack space when
- inlining similar arrays from multiple callees into one caller.
-
LLVM includes a new experimental Static Single Information (SSI)
- construction pass.
LLVM has a new "EngineBuilder" class which makes it more obvious how to
- set up and configure an ExecutionEngine (a JIT or interpreter).
-
The JIT now supports generating more than 16M of code.
-
When configured with --with-oprofile, the JIT can now inform
- OProfile about JIT'd code, allowing OProfile to get line number and function
- name information for JIT'd functions.
-
When "libffi" is available, the LLVM interpreter now uses it, which supports
- calling almost arbitrary external (natively compiled) functions.
-
Clients of the JIT can now register a 'JITEventListener' object to receive
- callbacks when the JIT emits or frees machine code. The OProfile support
- uses this mechanism.
We have put a significant amount of work into the code generator
-infrastructure, which allows us to implement more aggressive algorithms and make
-it run faster:
-
-
-
-
The llc -asm-verbose option (exposed from llvm-gcc as -dA
- and clang as -fverbose-asm or -dA) now adds a lot of
- useful information in comments to
- the generated .s file. This information includes location information (if
- built with -g) and loop nest information.
-
The code generator now supports a new MachineVerifier pass which is useful
- for finding bugs in targets and codegen passes.
-
The Machine LICM is now enabled by default. It hoists instructions out of
- loops (such as constant pool loads, loads from read-only stubs, vector
- constant synthesization code, etc.) and is currently configured to only do
- so when the hoisted operation can be rematerialized.
-
The Machine Sinking pass is now enabled by default. This pass moves
- side-effect free operations down the CFG so that they are executed on fewer
- paths through a function.
-
The code generator now performs "stack slot coloring" of register spills,
- which allows spill slots to be reused. This leads to smaller stack frames
- in cases where there are lots of register spills.
-
The register allocator has many improvements to take better advantage of
- commutable operations, various spiller peephole optimizations, and can now
- coalesce cross-register-class copies.
-
Tblgen now supports multiclass inheritance and a number of new string and
- list operations like !(subst), !(foreach), !car,
- !cdr, !null, !if, !cast.
- These make the .td files more expressive and allow more aggressive factoring
- of duplication across instruction patterns.
-
Target-specific intrinsics can now be added without having to hack VMCore to
- add them. This makes it easier to maintain out-of-tree targets.
-
The instruction selector is better at propagating information about values
- (such as whether they are sign/zero extended etc.) across basic block
- boundaries.
-
The SelectionDAG datastructure has new nodes for representing buildvector
- and vector shuffle operations. This
- makes operations and pattern matching more efficient and easier to get
- right.
-
The Prolog/Epilog Insertion Pass now has experimental support for performing
- the "shrink wrapping" optimization, which moves spills and reloads around in
- the CFG to avoid doing saves on paths that don't need them.
-
LLVM includes new experimental support for writing ELF .o files directly
- from the compiler. It works well for many simple C testcases, but doesn't
- support exception handling, debug info, inline assembly, etc.
-
Targets can now specify register allocation hints through
- MachineRegisterInfo::setRegAllocationHint. A regalloc hint consists
- of hint type and physical register number. A hint type of zero specifies a
- register allocation preference. Other hint type values are target specific
- which are resolved by TargetRegisterInfo::ResolveRegAllocHint. An
- example is the ARM target which uses register hints to request that the
- register allocator provide an even / odd register pair to two virtual
- registers.
GCC-compatible soft float modes are now supported, which are typically used
- by OS kernels.
-
X86-64 now models implicit zero extensions better, which allows the code
- generator to remove a lot of redundant zexts. It also models the 8-bit "H"
- registers as subregs, which allows them to be used in some tricky
- situations.
-
X86-64 now supports the "local exec" and "initial exec" thread local storage
- model.
-
The vector forms of the icmp and fcmp instructions now select to efficient
- SSE operations.
-
Support for the win64 calling conventions have improved. The primary
- missing feature is support for varargs function definitions. It seems to
- work well for many win64 JIT purposes.
-
The X86 backend has preliminary support for mapping address spaces to segment
- register references. This allows you to write GS or FS relative memory
- accesses directly in LLVM IR for cases where you know exactly what you're
- doing (such as in an OS kernel). There are some known problems with this
- support, but it works in simple cases.
-
The X86 code generator has been refactored to move all global variable
- reference logic to one place
- (X86Subtarget::ClassifyGlobalReference) which
- makes it easier to reason about.
Preliminary support for processors, such as the Cortex-A8 and Cortex-A9,
-that implement version v7-A of the ARM architecture. The ARM backend now
-supports both the Thumb2 and Advanced SIMD (Neon) instruction sets.
-
-
The AAPCS-VFP "hard float" calling conventions are also supported with the
--float-abi=hard flag.
-
-
The ARM calling convention code is now tblgen generated instead of resorting
- to C++ code.
-
-
-
These features are still somewhat experimental
-and subject to change. The Neon intrinsics, in particular, may change in future
-releases of LLVM. ARMv7 support has progressed a lot on top of tree since 2.6
-branched.
This release includes a number of new APIs that are used internally, which
- may also be useful for external clients.
-
-
-
-
New
- PrettyStackTrace class allows crashes of llvm tools (and applications
- that integrate them) to provide more detailed indication of what the
- compiler was doing at the time of the crash (e.g. running a pass).
- At the top level for each LLVM tool, it includes the command line arguments.
-
-
New StringRef
- and Twine classes
- make operations on character ranges and
- string concatenation to be more efficient. StringRef is just a const
- char* with a length, Twine is a light-weight rope.
-
LLVM has new WeakVH, AssertingVH and CallbackVH
- classes, which make it easier to write LLVM IR transformations. WeakVH
- is automatically drops to null when the referenced Value is deleted,
- and is updated across a replaceAllUsesWith operation.
- AssertingVH aborts the program if the
- referenced value is destroyed while it is being referenced. CallbackVH
- is a customizable class for handling value references. See ValueHandle.h
- for more information.
-
The new 'Triple
- ' class centralizes a lot of logic that reasons about target
- triples.
-
The new '
- llvm_report_error()' set of APIs allows tools to embed the LLVM
- optimizer and backend and recover from previously unrecoverable errors.
LLVM has new
- SourceMgr and SMLoc classes which implement caret
- diagnostics and basic include stack processing for simple parsers. It is
- used by tablegen, llvm-mc, the .ll parser and FileCheck.
LLVM now includes a new internal 'FileCheck' tool which allows
- writing much more accurate regression tests that run faster. Please see the
- FileCheck section of the Testing
- Guide for more information.
-
LLVM profile information support has been significantly improved to produce
-correct use counts, and has support for edge profiling with reduced runtime
-overhead. Combined, the generated profile information is both more correct and
-imposes about half as much overhead (2.6. from 12% to 6% overhead on SPEC
-CPU2000).
-
The C bindings (in the llvm/include/llvm-c directory) include many newly
- supported APIs.
-
LLVM 2.6 includes a brand new experimental LLVM bindings to the Ada2005
- programming language.
-
-
The LLVMC driver has several new features:
-
-
Dynamic plugins now work on Windows.
-
New option property: init. Makes possible to provide default values for
- options defined in plugins (interface to cl::init).
-
New example: Skeleton, shows how to create a standalone LLVMC-based
- driver.
-
New example: mcc16, a driver for the PIC16 toolchain.
If you're already an LLVM user or developer with out-of-tree changes based
-on LLVM 2.5, this section lists some "gotchas" that you may run into upgrading
-from the previous release.
-
-
-
The Itanium (IA64) backend has been removed. It was not actively supported
- and had bitrotted.
-
The BigBlock register allocator has been removed, it had also bitrotted.
-
The C Backend (-march=c) is no longer considered part of the LLVM release
-criteria. We still want it to work, but no one is maintaining it and it lacks
-support for arbitrary precision integers and other important IR features.
-
-
All LLVM tools now default to overwriting their output file, behaving more
- like standard unix tools. Previously, this only happened with the '-f'
- option.
-
LLVM build now builds all libraries as .a files instead of some
- libraries as relinked .o files. This requires some APIs like
- InitializeAllTargets.h.
-
-
-
-
-
In addition, many APIs have changed in this release. Some of the major LLVM
-API changes are:
-
-
-
All uses of hash_set and hash_map have been removed from
- the LLVM tree and the wrapper headers have been removed.
-
The llvm/Streams.h and DOUT member of Debug.h have been removed. The
- llvm::Ostream class has been completely removed and replaced with
- uses of raw_ostream.
-
LLVM's global uniquing tables for Types and Constants have
- been privatized into members of an LLVMContext. A number of APIs
- now take an LLVMContext as a parameter. To smooth the transition
- for clients that will only ever use a single context, the new
- getGlobalContext() API can be used to access a default global
- context which can be passed in any and all cases where a context is
- required.
-
The getABITypeSize methods are now called getAllocSize.
-
The Add, Sub and Mul operators are no longer
- overloaded for floating-point types. Floating-point addition, subtraction
- and multiplication are now represented with new operators FAdd,
- FSub and FMul. In the IRBuilder API,
- CreateAdd, CreateSub, CreateMul and
- CreateNeg should only be used for integer arithmetic now;
- CreateFAdd, CreateFSub, CreateFMul and
- CreateFNeg should now be used for floating-point arithmetic.
-
The DynamicLibrary class can no longer be constructed, its functionality has
- moved to static member functions.
-
raw_fd_ostream's constructor for opening a given filename now
- takes an extra Force argument. If Force is set to
- false, an error will be reported if a file with the given name
- already exists. If Force is set to true, the file will
- be silently truncated (which is the behavior before this flag was
- added).
-
SCEVHandle no longer exists, because reference counting is no
- longer done for SCEV* objects, instead const SCEV*
- should be used.
-
-
Many APIs, notably llvm::Value, now use the StringRef
-and Twine classes instead of passing const char*
-or std::string, as described in
-the Programmer's Manual. Most
-clients should be unaffected by this transition, unless they are used to
-Value::getName() returning a string. Here are some tips on updating to
-2.6:
-
-
getNameStr() is still available, and matches the old
- behavior. Replacing getName() calls with this is an safe option,
- although more efficient alternatives are now possible.
-
-
If you were just relying on getName() being able to be sent to
- a std::ostream, consider migrating
- to llvm::raw_ostream.
-
-
If you were using getName().c_str() to get a const
- char* pointer to the name, you can use getName().data().
- Note that this string (as before), may not be the entire name if the
- name contains embedded null characters.
-
-
If you were using operator + on the result of getName() and
- treating the result as an std::string, you can either
- use Twine::str to get the result as an std::string, or
- could move to a Twine based design.
-
-
isName() should be replaced with comparison
- against getName() (this is now efficient).
-
-
-
-
The registration interfaces for backend Targets has changed (what was
-previously TargetMachineRegistry). For backend authors, see the Writing An LLVM Backend
-guide. For clients, the notable API changes are:
-
-
TargetMachineRegistry has been renamed
- to TargetRegistry.
-
-
Clients should move to using the TargetRegistry::lookupTarget()
- function to find targets.
Intel and AMD machines (IA32, X86-64, AMD64, EMT-64) running Red Hat
- Linux, Fedora Core, FreeBSD and AuroraUX (and probably other unix-like
- systems).
-
PowerPC and X86-based Mac OS X systems, running 10.3 and above in 32-bit
- and 64-bit modes.
-
Intel and AMD machines running on Win32 using MinGW libraries (native).
-
Intel and AMD machines running on Win32 with the Cygwin libraries (limited
- support is available for native builds with Visual C++).
-
Sun UltraSPARC workstations running Solaris 10.
-
Alpha-based machines running Debian GNU/Linux.
-
-
-
The core LLVM infrastructure uses GNU autoconf to adapt itself
-to the machine and operating system on which it is built. However, minor
-porting may be required to get LLVM to work on new platforms. We welcome your
-portability patches and reports of successful builds or error messages.
This section contains significant known problems with the LLVM system,
-listed by component. If you run into a problem, please check the LLVM bug database and submit a bug if
-there isn't already one.
-
-
-
The llvm-gcc bootstrap will fail with some versions of binutils (e.g. 2.15)
- with a message of "Error: can not do 8
- byte pc-relative relocation" when building C++ code. We intend to
- fix this on mainline, but a workaround for 2.6 is to upgrade to binutils
- 2.17 or later.
-
-
LLVM will not correctly compile on Solaris and/or OpenSolaris
-using the stock GCC 3.x.x series 'out the box',
-See: Broken versions of GCC and other tools.
-However, A Modern GCC Build
-for x86/x86-64 has been made available from the third party AuroraUX Project
-that has been meticulously tested for bootstrapping LLVM & Clang.
The following components of this LLVM release are either untested, known to
-be broken or unreliable, or are in early development. These components should
-not be relied on, and bugs should not be filed against them, but they may be
-useful to some people. In particular, if you would like to work on one of these
-components, please contact us on the LLVMdev list.
-
-
-
The MSIL, Alpha, SPU, MIPS, PIC16, Blackfin, MSP430 and SystemZ backends are
- experimental.
-
The llc "-filetype=asm" (the default) is the only
- supported value for this option. The ELF writer is experimental.
-
The implementation of Andersen's Alias Analysis has many known bugs.
The X86 backend generates inefficient floating point code when configured
- to generate code for systems that don't have SSE2.
-
Win64 code generation wasn't widely tested. Everything should work, but we
- expect small issues to happen. Also, llvm-gcc cannot build the mingw64
- runtime currently due
- to several
- bugs and due to lack of support for
- the
- 'u' inline assembly constraint and for X87 floating point inline assembly.
-
The X86-64 backend does not yet support the LLVM IR instruction
- va_arg. Currently, the llvm-gcc and front-ends support variadic
- argument constructs on X86-64 by lowering them manually.
Support for the Advanced SIMD (Neon) instruction set is still incomplete
-and not well tested. Some features may not work at all, and the code quality
-may be poor in some cases.
-
Thumb mode works only on ARMv6 or higher processors. On sub-ARMv6
-processors, thumb programs can crash or produce wrong
-results (PR1388).
-
Compilation for ARM Linux OABI (old ABI) is supported but not fully tested.
-
The only major language feature of GCC not supported by llvm-gcc is
- the __builtin_apply family of builtins. However, some extensions
- are only supported on some targets. For example, trampolines are only
- supported on some targets (these are used when you take the address of a
- nested function).
-
-
If you run into GCC extensions which are not supported, please let us know.
-
-The llvm-gcc 4.2 Ada compiler works fairly well; however, this is not a mature
-technology, and problems should be expected.
-
-
The Ada front-end currently only builds on X86-32. This is mainly due
-to lack of trampoline support (pointers to nested functions) on other platforms.
-However, it also fails to build on X86-64
-which does support trampolines.
-
The Ada front-end fails to bootstrap.
-This is due to lack of LLVM support for setjmp/longjmp style
-exception handling, which is used internally by the compiler.
-Workaround: configure with --disable-bootstrap.
-
The c380004, c393010
-and cxg2021 ACATS tests fail
-(c380004 also fails with gcc-4.2 mainline).
-If the compiler is built with checks disabled then c393010
-causes the compiler to go into an infinite loop, using up all system memory.
-
Some GCC specific Ada tests continue to crash the compiler.
-
The -E binder option (exception backtraces)
-does not work and will result in programs
-crashing if an exception is raised. Workaround: do not use -E.
-
Only discrete types are allowed to start
-or finish at a non-byte offset in a record. Workaround: do not pack records
-or use representation clauses that result in a field of a non-discrete type
-starting or finishing in the middle of a byte.
The Llvm.Linkage module is broken, and has incorrect values. Only
-Llvm.Linkage.External, Llvm.Linkage.Available_externally, and
-Llvm.Linkage.Link_once will be correct. If you need any of the other linkage
-modes, you'll have to write an external C library in order to expose the
-functionality. This has been fixed in the trunk.
A wide variety of additional information is available on the LLVM web page, in particular in the documentation section. The web page also
-contains versions of the API documentation which is up-to-date with the
-Subversion version of the source code.
-You can access versions of these documents specific to this release by going
-into the "llvm/doc/" directory in the LLVM tree.
-
-
If you have any questions or comments about LLVM, please feel free to contact
-us via the mailing
-lists.
This document contains the release notes for the LLVM Compiler
-Infrastructure, release 2.5. Here we describe the status of LLVM, including
+Infrastructure, release 2.6. Here we describe the status of LLVM, including
major improvements from the previous release and significant known problems.
All LLVM releases may be downloaded from the LLVM releases web site.
-The LLVM 2.5 distribution currently consists of code from the core LLVM
-repository —which roughly includes the LLVM optimizers, code generators
-and supporting tools — and the llvm-gcc repository. In addition to this
-code, the LLVM Project includes other sub-projects that are in development. The
-two which are the most actively developed are the Clang
-Project and the VMKit Project.
+The LLVM 2.6 distribution currently consists of code from the core LLVM
+repository (which roughly includes the LLVM optimizers, code generators
+and supporting tools), the Clang repository and the llvm-gcc repository. In
+addition to this code, the LLVM Project includes other sub-projects that are in
+development. Here we include updates on these subprojects.
@@ -99,37 +110,30 @@
The Clang project is an effort to build
-a set of new 'LLVM native' front-end technologies for the LLVM optimizer and
-code generator. While Clang is not included in the LLVM 2.5 release, it is
-continuing to make major strides forward in all areas. Its C and Objective-C
-parsing and code generation support is now very solid. For example, it is
-capable of successfully building many real-world applications for X86-32
-and X86-64,
-including the FreeBSD
-kernel and gcc 4.2. C++ is also
-making incredible progress,
-and work on templates has recently started. If you are
-interested in fast compiles and good diagnostics, we encourage you to try it out
-by building from mainline
-and reporting any issues you hit to the fast compiles and
+good diagnostics, we
+encourage you to try it out. Clang currently compiles typical Objective-C code
+3x faster than GCC and compiles C code about 30% faster than GCC at -O0 -g
+(which is when the most pressure is on the frontend).
+
+
In addition to supporting these languages, C++ support is also well under way, and mainline
+Clang is able to parse the libstdc++ 4.2 headers and even codegen simple apps.
+If you are interested in Clang C++ support or any other Clang feature, we
+strongly encourage you to get involved on the Clang front-end mailing
list.
-
In the LLVM 2.5 time-frame, the Clang team has made many improvements:
+
In the LLVM 2.6 time-frame, the Clang team has made many improvements:
-
Clang now has a new driver, which is focused on providing a GCC-compatible
- interface.
-
The X86-64 ABI is now supported, including support for the Apple
- 64-bit Objective-C runtime and zero cost exception handling.
-
Precompiled header support is now implemented.
-
Objective-C support is significantly improved beyond LLVM 2.4, supporting
- many features, such as Objective-C Garbage Collection.
-
Variable length arrays are now fully supported.
-
C99 designated initializers are now fully supported.
-
Clang now includes all major compiler headers, including a
- redesigned tgmath.h and several more intrinsic headers.
-
Many many bugs are fixed and many features have been added.
+
C and Objective-C support are now considered production quality.
+
AuroraUX, FreeBSD and OpenBSD are now supported.
+
Most of Objective-C 2.0 is now supported with the GNU runtime.
+
Many many bugs are fixed and lots of features have been added.
@@ -140,19 +144,18 @@
-
Previously announced in the last LLVM release, the Clang project also
+
Previously announced in the 2.4 and 2.5 LLVM releases, the Clang project also
includes an early stage static source code analysis tool for automatically finding bugs
-in C and Objective-C programs. The tool performs a growing set of checks to find
+in C and Objective-C programs. The tool performs checks to find
bugs that occur on a specific path within a program.
-
In the LLVM 2.5 time-frame there have been many significant improvements to
-the analyzer's core path simulation engine and machinery for generating
-path-based bug reports to end-users. Particularly noteworthy improvements
-include experimental support for full field-sensitivity and reasoning about heap
-objects as well as an improved value-constraints subengine that does a much
-better job of reasoning about inequality relationships (e.g., x > 2)
-between variables and constants.
+
In the LLVM 2.6 time-frame, the analyzer core has undergone several important
+improvements and cleanups and now includes a new Checker interface that
+is intended to eventually serve as a basis for domain-specific checks. Further,
+in addition to generating HTML files for reporting analysis results, the
+analyzer can now also emit bug reports in a structured XML format that is
+intended to be easily readable by other programs.
The set of checks performed by the static analyzer continues to expand, and
future plans for the tool include full source-level inter-procedural analysis
@@ -170,44 +173,191 @@
The VMKit project is an implementation of
-a JVM and a CLI Virtual Machines (Microsoft .NET is an
-implementation of the CLI) using the Just-In-Time compiler of LLVM.
+a JVM and a CLI Virtual Machine (Microsoft .NET is an
+implementation of the CLI) using LLVM for static and just-in-time
+compilation.
-
Following LLVM 2.5, VMKit has its second release that you can find on its
-webpage. The release includes
+
+VMKit version 0.26 builds with LLVM 2.6 and you can find it on its
+web page. The release includes
bug fixes, cleanup and new features. The major changes are:
-
Ahead of Time compiler: compiles .class files to llvm .bc. VMKit uses this
-functionality to native compile the standard classes (e.g. java.lang.String).
-Users can compile AoT .class files into dynamic libraries and run them with the
-help of VMKit.
-
-
New exception model: the dwarf exception model is very slow for
-exception-intensive applications, so the JVM has had a new implementation of
-exceptions which check at each function call if an exception happened. There is
-a low performance penalty on applications without exceptions, but it is a big
-gain for exception-intensive applications. For example the jack benchmark in
-Spec JVM98 is 6x faster (performance gain of 83%).
+
A new llcj tool to generate shared libraries or executables of Java
+ files.
+
Cooperative garbage collection.
+
Fast subtype checking (paper from Click et al [JGI'02]).
+
Implementation of a two-word header for Java objects instead of the original
+ three-word header.
+
Better Java specification-compliance: division by zero checks, stack
+ overflow checks, finalization and references support.
-
User-level management of thread stacks, so that thread local data access
-at runtime is fast and portable.
+
+
-
Implementation of biased locking for faster object synchronizations at
-runtime.
-
New support for OSX/X64, Linux/X64 (with the Boehm GC) and Linux/ppc32.
+The new LLVM compiler-rt project
+is a simple library that provides an implementation of the low-level
+target-specific hooks required by code generation and other runtime components.
+For example, when compiling for a 32-bit target, converting a double to a 64-bit
+unsigned integer is compiled into a runtime call to the "__fixunsdfdi"
+function. The compiler-rt library provides highly optimized implementations of
+this and other low-level routines (some are 3x faster than the equivalent
+libgcc routines).
+
+
+All of the code in the compiler-rt project is available under the standard LLVM
+License, a "BSD-style" license.
+The new LLVM KLEE project is a symbolic
+execution framework for programs in LLVM bitcode form. KLEE tries to
+symbolically evaluate "all" paths through the application and records state
+transitions that lead to fault states. This allows it to construct testcases
+that lead to faults and can even be used to verify algorithms. For more
+details, please see the OSDI 2008 paper about
+KLEE.
+The goal of DragonEgg is to make
+gcc-4.5 act like llvm-gcc without requiring any gcc modifications whatsoever.
+DragonEgg is a shared library (llvm.so)
+that is loaded by gcc at runtime. It uses the new gcc plugin architecture to
+disable the GCC optimizers and code generators, and schedule the LLVM optimizers
+and code generators (or direct output of LLVM IR) instead. Currently only Linux
+and Darwin are supported, and only on x86-32 and x86-64. It should be easy to
+add additional unix-like architectures and other processor families. In theory
+it should be possible to use DragonEgg
+with any language supported by gcc, however only C and Fortran work well for the
+moment. Ada and C++ work to some extent, while Java, Obj-C and Obj-C++ are so
+far entirely untested. Since gcc-4.5 has not yet been released, neither has
+DragonEgg. To build
+DragonEgg you will need to check out the
+development versions of gcc,
+llvm and
+DragonEgg from their respective
+subversion repositories, and follow the instructions in the
+DragonEgg README.
+
+The LLVM Machine Code (MC) Toolkit project is a (very early) effort to build
+better tools for dealing with machine code, object file formats, etc. The idea
+is to be able to generate most of the target specific details of assemblers and
+disassemblers from existing LLVM target .td files (with suitable enhancements),
+and to build infrastructure for reading and writing common object file formats.
+One of the first deliverables is to build a full assembler and integrate it into
+the compiler, which is predicted to substantially reduce compile time in some
+scenarios.
+
+
+
In the LLVM 2.6 timeframe, the MC framework has grown to the point where it
+can reliably parse and pretty print (with some encoding information) a
+darwin/x86 .s file successfully, and has the very early phases of a Mach-O
+assembler in progress. Beyond the MC framework itself, major refactoring of the
+LLVM code generator has started. The idea is to make the code generator reason
+about the code it is producing in a much more semantic way, rather than a
+textual way. For example, the code generator now uses MCSection objects to
+represent section assignments, instead of text strings that print to .section
+directives.
+
+
MC is an early and ongoing project that will hopefully continue to lead to
+many improvements in the code generator and build infrastructure useful for many
+other situations.
+
An exciting aspect of LLVM is that it is used as an enabling technology for
+ a lot of other language and tools projects. This section lists some of the
+ projects that have already been updated to work with LLVM 2.6.
Rubinius is an environment
+for running Ruby code which strives to write as much of the core class
+implementation in Ruby as possible. Combined with a bytecode interpreting VM, it
+uses LLVM to optimize and compile ruby code down to machine code. Techniques
+such as type feedback, method inlining, and uncommon traps are all used to
+remove dynamism from ruby execution and increase performance.
+
+
Since LLVM 2.5, Rubinius has made several major leaps forward, implementing
+a counter based JIT, type feedback and speculative method inlining.
+
+MacRuby is an implementation of Ruby on top of
+core Mac OS X technologies, such as the Objective-C common runtime and garbage
+collector and the CoreFoundation framework. It is principally developed by
+Apple and aims at enabling the creation of full-fledged Mac OS X applications.
+
+
+
+MacRuby uses LLVM for optimization passes, JIT and AOT compilation of Ruby
+expressions. It also uses zero-cost DWARF exceptions to implement Ruby exception
+handling.
+
+
+
+
Pure
@@ -224,12 +374,8 @@
an easy-to-use C interface. The interpreter uses LLVM as a backend to
JIT-compile Pure programs to fast native code.
-
In addition to the usual algebraic data structures, Pure also has
-MATLAB-style matrices in order to support numeric computations and signal
-processing in an efficient way. Pure is mainly aimed at mathematical
-applications right now, but it has been designed as a general purpose language.
-The dynamic interpreter environment and the C interface make it possible to use
-it as a kind of functional scripting language for many application areas.
+
Pure versions 0.31 and later have been tested and are known to work with
+LLVM 2.6 (and continue to work with older LLVM releases >= 2.3 as well).
@@ -243,11 +389,11 @@
LDC is an implementation of
the D Programming Language using the LLVM optimizer and code generator.
-The LDC project works great with the LLVM 2.5 release. General improvements in
+The LDC project works great with the LLVM 2.6 release. General improvements in
this
cycle have included new inline asm constraint handling, better debug info
-support, general bugfixes, and better x86-64 support. This has allowed
-some major improvements in LDC, getting us much closer to being as
+support, general bug fixes and better x86-64 support. This has allowed
+some major improvements in LDC, getting it much closer to being as
fully featured as the original DMD compiler from DigitalMars.
+Roadsend PHP (rphp) is an open
source implementation of the PHP programming
-language that uses LLVM for its optimizer, JIT, and static compiler. This is a
+language that uses LLVM for its optimizer, JIT and static compiler. This is a
reimplementation of an earlier project that is now based on LLVM.
This release includes a huge number of bug fixes, performance tweaks, and
-minor improvements. Some of the major improvements and new features are listed
-in this section.
-
+
+Unladen Swallow is a
+branch of Python intended to be fully
+compatible and significantly faster. It uses LLVM's optimization passes and JIT
+compiler.
+LLVM-Lua uses LLVM to add JIT
+and static compiling support to the Lua VM. Lua bytecode is analyzed to
+remove type checks, then LLVM is used to compile the bytecode down to machine
+code.
+IcedTea provides a
+harness to build OpenJDK using only free software build tools and to provide
+replacements for the not-yet free parts of OpenJDK. One of the extensions that
+IcedTea provides is a new JIT compiler named Shark which uses LLVM
+to provide native code generation without introducing processor-dependent
+code.
+
+
-
llvm-gcc now generally supports the GFortran front-end, and the precompiled
-release binaries now support Fortran, even on Mac OS/X.
-
CMake is now used by the LLVM build process
-on Windows. It automatically generates Visual Studio project files (and
-more) from a set of simple text files. This makes it much easier to
-maintain. In time, we'd like to standardize on CMake for everything.
-
LLVM 2.5 now uses (and includes) Google Test for unit testing.
The LLVM native code generator now supports arbitrary precision integers.
-Types like i33 have long been valid in the LLVM IR, but were previously
-only supported by the interpreter. Note that the C backend still does not
-support these.
+
-
LLVM 2.5 no longer uses 'bison,' so it is easier to build on Windows.
-
+
This release includes a huge number of bug fixes, performance tweaks and
+minor improvements. Some of the major improvements and new features are listed
+in this section.
+
LLVM fully supports the llvm-gcc 4.2 front-end, which marries the GCC
-front-ends and driver with the LLVM optimizer and code generator. It currently
-includes support for the C, C++, Objective-C, Ada, and Fortran front-ends.
+
LLVM 2.6 includes several major new capabilities:
-
In this release, the GCC inliner is completely disabled. Previously the GCC
-inliner was used to handle always-inline functions and other cases. This caused
-problems with code size growth, and it is completely disabled in this
-release.
-
-
llvm-gcc (and LLVM in general) now support code generation for stack
-canaries, which is an effective form of buffer overflow
-protection. llvm-gcc supports this with the -fstack-protector
-command line option (just like GCC). In LLVM IR, you can request code
-generation for stack canaries with function attributes.
-
Debug information now includes line numbers when optimizations are enabled.
+ This allows statistical sampling tools like OProfile and Shark to map
+ samples back to source lines.
+
LLVM now includes new experimental backends to support the MSP430, SystemZ
+ and BlackFin architectures.
LLVM now supports doing optimization and code generation on multiple
+ threads. Please see the LLVM
+ Programmer's Manual for more information.
+
LLVM now has experimental support for embedded
+ metadata in LLVM IR, though the implementation is not guaranteed to be
+ final and the .bc file format may change in future releases. Debug info
+ does not yet use this format in LLVM 2.6.
LLVM IR has several new features that are used by our existing front-ends and
-can be useful if you are writing a front-end for LLVM:
+
LLVM IR has several new features for better support of new targets and that
+expose new optimization opportunities:
-
The shufflevector instruction
-has been generalized to allow different shuffle mask width than its input
-vectors. This allows you to use shufflevector to combine two
-"<4 x float>" vectors into a "<8 x float>" for example.
-
-
LLVM IR now supports new intrinsics for computing and acting on overflow of integer operations. This allows
-efficient code generation for languages that must trap or throw an exception on
-overflow. While these intrinsics work on all targets, they only generate
-efficient code on X86 so far.
-
-
LLVM IR now supports a new private
-linkage type to produce labels that are stripped by the assembler before it
-produces a .o file (thus they are invisible to the linker).
-
-
LLVM IR supports two new attributes for better alias analysis. The noalias attribute can now be used on the
-return value of a function to indicate that it returns new memory (e.g.
-'malloc', 'calloc', etc).
-The new nocapture attribute can be used
-on pointer arguments to indicate that the function does not return the pointer,
-store it in an object that outlives the call, or let the value of the pointer
-escape from the function in any other way.
-Note that it is the pointer itself that must not escape, not the value it
-points to: loading a value out of the pointer is perfectly fine.
-Many standard library functions (e.g. 'strlen', 'memcpy') have this property.
-
-
-
-
The parser for ".ll" files in lib/AsmParser is now completely rewritten as a
-recursive descent parser. This parser produces better error messages (including
-caret diagnostics), is less fragile (less likely to crash on strange things),
-does not leak memory, is more efficient, and eliminates LLVM's last use of the
-'bison' tool.
-
-
Debug information representation and manipulation internals have been
- consolidated to use a new set of classes in
- llvm/Analysis/DebugInfo.h. These routines are more
- efficient, robust, and extensible and replace the older mechanisms.
- llvm-gcc, clang, and the code generator now use them to create and process
- debug information.
-
+
The add, sub and mul
+ instructions have been split into integer and floating point versions (like
+ divide and remainder), introducing new fadd, fsub,
+ and fmul instructions.
+
The add, sub and mul
+ instructions now support optional "nsw" and "nuw" bits which indicate that
+ the operation is guaranteed to not overflow (in the signed or
+ unsigned case, respectively). This gives the optimizer more information and
+ can be used for things like C signed integer values, which are undefined on
+ overflow.
+
The sdiv instruction now supports an
+ optional "exact" flag which indicates that the result of the division is
+ guaranteed to have a remainder of zero. This is useful for optimizing pointer
+ subtraction in C.
+
The getelementptr instruction now
+ supports arbitrary integer index values for array/pointer indices. This
+ allows for better code generation on 16-bit pointer targets like PIC16.
+
The getelementptr instruction now
+ supports an "inbounds" optimization hint that tells the optimizer that the
+ pointer is guaranteed to be within its allocated object.
+
LLVM now support a series of new linkage types for global values which allow
+ for better optimization and new capabilities:
+
+
linkonce_odr and
+ weak_odr have the same linkage
+ semantics as the non-"odr" linkage types. The difference is that these
+ linkage types indicate that all definitions of the specified function
+ are guaranteed to have the same semantics. This allows inlining
+ templates functions in C++ but not inlining weak functions in C,
+ which previously both got the same linkage type.
+
available_externally
+ is a new linkage type that gives the optimizer visibility into the
+ definition of a function (allowing inlining and side effect analysis)
+ but that does not cause code to be generated. This allows better
+ optimization of "GNU inline" functions, extern templates, etc.
+
linker_private is a
+ new linkage type (which is only useful on Mac OS X) that is used for
+ some metadata generation and other obscure things.
+
+
Finally, target-specific intrinsics can now return multiple values, which
+ is useful for modeling target operations with multiple results.
@@ -405,27 +569,53 @@
-
In addition to a large array of bug fixes and minor performance tweaks, this
+
In addition to a large array of minor performance tweaks and bug fixes, this
release includes a few major enhancements and additions to the optimizers:
-
The loop optimizer now improves floating point induction variables in
-several ways, including adding shadow induction variables to avoid
-"integer <-> floating point" conversions in loops when safe.
+
The Scalar Replacement of Aggregates
+ pass has many improvements that allow it to better promote vector unions,
+ variables which are memset, and much more strange code that can happen to
+ do bitfield accesses to register operations. An interesting change is that
+ it now produces "unusual" integer sizes (like i1704) in some cases and lets
+ other optimizers clean things up.
+
The Loop Strength Reduction pass now
+ promotes small integer induction variables to 64-bit on 64-bit targets,
+ which provides a major performance boost for much numerical code. It also
+ promotes shorts to int on 32-bit hosts, etc. LSR now also analyzes pointer
+ expressions (e.g. getelementptrs), as well as integers.
+
The GVN pass now eliminates partial
+ redundancies of loads in simple cases.
+
The Inliner now reuses stack space when
+ inlining similar arrays from multiple callees into one caller.
+
LLVM includes a new experimental Static Single Information (SSI)
+ construction pass.
+
+
-
The "-mem2reg" pass is now much faster on code with large basic blocks.
+
-
The "-jump-threading" pass is more powerful: it is iterative
- and handles threading based on values with fully and partially redundant
- loads.
-
The "-memdep" memory dependence analysis pass (used by GVN and memcpyopt) is
- both faster and more aggressive.
The "-scalarrepl" scalar replacement of aggregates pass is more aggressive
- about promoting unions to registers.
+
+
+
LLVM has a new "EngineBuilder" class which makes it more obvious how to
+ set up and configure an ExecutionEngine (a JIT or interpreter).
+
The JIT now supports generating more than 16M of code.
+
When configured with --with-oprofile, the JIT can now inform
+ OProfile about JIT'd code, allowing OProfile to get line number and function
+ name information for JIT'd functions.
+
When "libffi" is available, the LLVM interpreter now uses it, which supports
+ calling almost arbitrary external (natively compiled) functions.
+
Clients of the JIT can now register a 'JITEventListener' object to receive
+ callbacks when the JIT emits or frees machine code. The OProfile support
+ uses this mechanism.
The SelectionDAG type legalization logic has been completely rewritten, is
-now more powerful (it supports arbitrary precision integer types for example),
-and is more correct in several corner cases. The type legalizer converts
-operations on types that are not natively supported by the target machine into
-equivalent code sequences that only use natively supported types. The old type
-legalizer is still available (for now) and will be used if
--disable-legalize-types is passed to the code generator.
-
-
The code generator now supports widening illegal vectors to larger legal
-ones (for example, converting operations on <3 x float> to work on
-<4 x float>) which is very important for common graphics
-applications.
-
-
The assembly printers for each target are now split out into their own
-libraries that are separate from the main code generation logic. This reduces
-the code size of JIT compilers by not requiring them to be linked in.
-
-
The 'fast' instruction selection path (used at -O0 and for fast JIT
- compilers) now supports accelerating codegen for code that uses exception
- handling constructs.
-
-
The optional PBQP register allocator now supports register coalescing.
+
The llc -asm-verbose option (exposed from llvm-gcc as -dA
+ and clang as -fverbose-asm or -dA) now adds a lot of
+ useful information in comments to
+ the generated .s file. This information includes location information (if
+ built with -g) and loop nest information.
+
The code generator now supports a new MachineVerifier pass which is useful
+ for finding bugs in targets and codegen passes.
+
The Machine LICM is now enabled by default. It hoists instructions out of
+ loops (such as constant pool loads, loads from read-only stubs, vector
+ constant synthesization code, etc.) and is currently configured to only do
+ so when the hoisted operation can be rematerialized.
+
The Machine Sinking pass is now enabled by default. This pass moves
+ side-effect free operations down the CFG so that they are executed on fewer
+ paths through a function.
+
The code generator now performs "stack slot coloring" of register spills,
+ which allows spill slots to be reused. This leads to smaller stack frames
+ in cases where there are lots of register spills.
+
The register allocator has many improvements to take better advantage of
+ commutable operations, various spiller peephole optimizations, and can now
+ coalesce cross-register-class copies.
+
Tblgen now supports multiclass inheritance and a number of new string and
+ list operations like !(subst), !(foreach), !car,
+ !cdr, !null, !if, !cast.
+ These make the .td files more expressive and allow more aggressive factoring
+ of duplication across instruction patterns.
+
Target-specific intrinsics can now be added without having to hack VMCore to
+ add them. This makes it easier to maintain out-of-tree targets.
+
The instruction selector is better at propagating information about values
+ (such as whether they are sign/zero extended etc.) across basic block
+ boundaries.
+
The SelectionDAG datastructure has new nodes for representing buildvector
+ and vector shuffle operations. This
+ makes operations and pattern matching more efficient and easier to get
+ right.
+
The Prolog/Epilog Insertion Pass now has experimental support for performing
+ the "shrink wrapping" optimization, which moves spills and reloads around in
+ the CFG to avoid doing saves on paths that don't need them.
+
LLVM includes new experimental support for writing ELF .o files directly
+ from the compiler. It works well for many simple C testcases, but doesn't
+ support exception handling, debug info, inline assembly, etc.
+
Targets can now specify register allocation hints through
+ MachineRegisterInfo::setRegAllocationHint. A regalloc hint consists
+ of hint type and physical register number. A hint type of zero specifies a
+ register allocation preference. Other hint type values are target specific
+ which are resolved by TargetRegisterInfo::ResolveRegAllocHint. An
+ example is the ARM target which uses register hints to request that the
+ register allocator provide an even / odd register pair to two virtual
+ registers.
@@ -482,37 +694,33 @@
-
The llvm.returnaddress
-intrinsic (which is used to implement __builtin_return_address) now
-supports non-zero stack depths on X86.
-
-
The X86 backend now supports code generation of vector shift operations
-using SSE instructions.
-
-
X86-64 code generation now takes advantage of red zone, unless the
--mno-red-zone option is specified.
-
-
The X86 backend now supports using address space #256 in LLVM IR as a way of
-performing memory references off the GS segment register. This allows a
-front-end to take advantage of very low-level programming techniques when
-targeting X86 CPUs. See test/CodeGen/X86/movgs.ll for a simple
-example.
-
-
The X86 backend now supports a -disable-mmx command line option to
- prevent use of MMX even on chips that support it. This is important for cases
- where code does not contain the proper llvm.x86.mmx.emms
- intrinsics.
-
-
The X86 JIT now detects the new Intel Core i7 and Atom chips and
- auto-configures itself appropriately for the features of these chips.
-
-
The JIT now supports exception handling constructs on Linux/X86-64 and
- Darwin/x86-64.
-
The JIT supports Thread Local Storage (TLS) on Linux/X86-32 but not yet on
- X86-64.
+
SSE 4.2 builtins are now supported.
+
GCC-compatible soft float modes are now supported, which are typically used
+ by OS kernels.
+
X86-64 now models implicit zero extensions better, which allows the code
+ generator to remove a lot of redundant zexts. It also models the 8-bit "H"
+ registers as subregs, which allows them to be used in some tricky
+ situations.
+
X86-64 now supports the "local exec" and "initial exec" thread local storage
+ model.
+
The vector forms of the icmp and fcmp instructions now select to efficient
+ SSE operations.
+
Support for the win64 calling conventions have improved. The primary
+ missing feature is support for varargs function definitions. It seems to
+ work well for many win64 JIT purposes.
+
The X86 backend has preliminary support for mapping address spaces to segment
+ register references. This allows you to write GS or FS relative memory
+ accesses directly in LLVM IR for cases where you know exactly what you're
+ doing (such as in an OS kernel). There are some known problems with this
+ support, but it works in simple cases.
+
The X86 code generator has been refactored to move all global variable
+ reference logic to one place
+ (X86Subtarget::ClassifyGlobalReference) which
+ makes it easier to reason about.
+
@@ -527,70 +735,156 @@
-
Both direct and indirect load/stores work now.
-
Logical, bitwise and conditional operations now work for integer data
-types.
-
Function calls involving basic types work now.
-
Support for integer arrays.
-
The compiler can now emit libcalls for operations not supported by m/c
-instructions.
-
Support for both data and ROM address spaces.
+
Support for floating-point, indirect function calls, and
+ passing/returning aggregate types to functions.
+
The code generator is able to generate debug info into output COFF files.
+
Support for placing an object into a specific section or at a specific
+ address in memory.
Things not yet supported:
-
Floating point.
-
Passing/returning aggregate types to and from functions.
Preliminary support for processors, such as the Cortex-A8 and Cortex-A9,
+that implement version v7-A of the ARM architecture. The ARM backend now
+supports both the Thumb2 and Advanced SIMD (Neon) instruction sets.
+
+
The AAPCS-VFP "hard float" calling conventions are also supported with the
+-float-abi=hard flag.
+
+
The ARM calling convention code is now tblgen generated instead of resorting
+ to C++ code.
+
+
+
These features are still somewhat experimental
+and subject to change. The Neon intrinsics, in particular, may change in future
+releases of LLVM. ARMv7 support has progressed a lot on top of tree since 2.6
+branched.
The Clang plugin was substantially improved and is now enabled
- by default. The command llvmc --clang can be now used as a
- synonym to ccc.
+
-
There is now a --check-graph option, which is supposed to catch
- common errors like multiple default edges, mismatched output/input language
- names and cycles. In general, these checks can't be done at compile-time
- because of the need to support plugins.
+
This release includes a number of new APIs that are used internally, which
+ may also be useful for external clients.
+
-
Plugins are now more flexible and can refer to compilation graph nodes and
- options defined in other plugins. To manage dependencies, a priority-sorting
- mechanism was introduced. This change affects the TableGen file syntax. See the
- documentation for details.
+
+
New
+ PrettyStackTrace class allows crashes of llvm tools (and applications
+ that integrate them) to provide more detailed indication of what the
+ compiler was doing at the time of the crash (e.g. running a pass).
+ At the top level for each LLVM tool, it includes the command line arguments.
+
+
New StringRef
+ and Twine classes
+ make operations on character ranges and
+ string concatenation to be more efficient. StringRef is just a const
+ char* with a length, Twine is a light-weight rope.
+
LLVM has new WeakVH, AssertingVH and CallbackVH
+ classes, which make it easier to write LLVM IR transformations. WeakVH
+ is automatically drops to null when the referenced Value is deleted,
+ and is updated across a replaceAllUsesWith operation.
+ AssertingVH aborts the program if the
+ referenced value is destroyed while it is being referenced. CallbackVH
+ is a customizable class for handling value references. See ValueHandle.h
+ for more information.
+
The new 'Triple
+ ' class centralizes a lot of logic that reasons about target
+ triples.
+
The new '
+ llvm_report_error()' set of APIs allows tools to embed the LLVM
+ optimizer and backend and recover from previously unrecoverable errors.
LLVM has new
+ SourceMgr and SMLoc classes which implement caret
+ diagnostics and basic include stack processing for simple parsers. It is
+ used by tablegen, llvm-mc, the .ll parser and FileCheck.
+
-
Hooks can now be provided with arguments. The syntax is "$CALL(MyHook,
- 'Arg1', 'Arg2', 'Arg3')".
-
A new option type: multi-valued option, for options that take more than one
- argument (for example, "-foo a b c").
+
-
New option properties: 'one_or_more', 'zero_or_more',
-'hidden' and 'really_hidden'.
The 'case' expression gained an 'error' action and
- an 'empty' test (equivalent to "(not (not_empty ...))").
+
+
Other miscellaneous features include:
-
Documentation now looks more consistent to the rest of the LLVM
- docs. There is also a man page now.
+
+
LLVM now includes a new internal 'FileCheck' tool which allows
+ writing much more accurate regression tests that run faster. Please see the
+ FileCheck section of the Testing
+ Guide for more information.
+
LLVM profile information support has been significantly improved to produce
+correct use counts, and has support for edge profiling with reduced runtime
+overhead. Combined, the generated profile information is both more correct and
+imposes about half as much overhead (2.6. from 12% to 6% overhead on SPEC
+CPU2000).
+
The C bindings (in the llvm/include/llvm-c directory) include many newly
+ supported APIs.
+
LLVM 2.6 includes a brand new experimental LLVM bindings to the Ada2005
+ programming language.
+
+
The LLVMC driver has several new features:
+
+
Dynamic plugins now work on Windows.
+
New option property: init. Makes possible to provide default values for
+ options defined in plugins (interface to cl::init).
+
New example: Skeleton, shows how to create a standalone LLVMC-based
+ driver.
+
New example: mcc16, a driver for the PIC16 toolchain.
+
+
@@ -605,13 +899,24 @@
If you're already an LLVM user or developer with out-of-tree changes based
-on LLVM 2.4, this section lists some "gotchas" that you may run into upgrading
+on LLVM 2.5, this section lists some "gotchas" that you may run into upgrading
from the previous release.
-
-
llvm-gcc defaults to -fno-math-errno on all X86 targets.
-
+
The Itanium (IA64) backend has been removed. It was not actively supported
+ and had bitrotted.
+
The BigBlock register allocator has been removed, it had also bitrotted.
+
The C Backend (-march=c) is no longer considered part of the LLVM release
+criteria. We still want it to work, but no one is maintaining it and it lacks
+support for arbitrary precision integers and other important IR features.
+
+
All LLVM tools now default to overwriting their output file, behaving more
+ like standard unix tools. Previously, this only happened with the '-f'
+ option.
+
LLVM build now builds all libraries as .a files instead of some
+ libraries as relinked .o files. This requires some APIs like
+ InitializeAllTargets.h.
+
@@ -619,8 +924,82 @@
API changes are:
-
Some deprecated interfaces to create Instruction subclasses, that
- were spelled with lower case "create," have been removed.
+
All uses of hash_set and hash_map have been removed from
+ the LLVM tree and the wrapper headers have been removed.
+
The llvm/Streams.h and DOUT member of Debug.h have been removed. The
+ llvm::Ostream class has been completely removed and replaced with
+ uses of raw_ostream.
+
LLVM's global uniquing tables for Types and Constants have
+ been privatized into members of an LLVMContext. A number of APIs
+ now take an LLVMContext as a parameter. To smooth the transition
+ for clients that will only ever use a single context, the new
+ getGlobalContext() API can be used to access a default global
+ context which can be passed in any and all cases where a context is
+ required.
+
The getABITypeSize methods are now called getAllocSize.
+
The Add, Sub and Mul operators are no longer
+ overloaded for floating-point types. Floating-point addition, subtraction
+ and multiplication are now represented with new operators FAdd,
+ FSub and FMul. In the IRBuilder API,
+ CreateAdd, CreateSub, CreateMul and
+ CreateNeg should only be used for integer arithmetic now;
+ CreateFAdd, CreateFSub, CreateFMul and
+ CreateFNeg should now be used for floating-point arithmetic.
+
The DynamicLibrary class can no longer be constructed, its functionality has
+ moved to static member functions.
+
raw_fd_ostream's constructor for opening a given filename now
+ takes an extra Force argument. If Force is set to
+ false, an error will be reported if a file with the given name
+ already exists. If Force is set to true, the file will
+ be silently truncated (which is the behavior before this flag was
+ added).
+
SCEVHandle no longer exists, because reference counting is no
+ longer done for SCEV* objects, instead const SCEV*
+ should be used.
+
+
Many APIs, notably llvm::Value, now use the StringRef
+and Twine classes instead of passing const char*
+or std::string, as described in
+the Programmer's Manual. Most
+clients should be unaffected by this transition, unless they are used to
+Value::getName() returning a string. Here are some tips on updating to
+2.6:
+
+
getNameStr() is still available, and matches the old
+ behavior. Replacing getName() calls with this is an safe option,
+ although more efficient alternatives are now possible.
+
+
If you were just relying on getName() being able to be sent to
+ a std::ostream, consider migrating
+ to llvm::raw_ostream.
+
+
If you were using getName().c_str() to get a const
+ char* pointer to the name, you can use getName().data().
+ Note that this string (as before), may not be the entire name if the
+ name contains embedded null characters.
+
+
If you were using operator + on the result of getName() and
+ treating the result as an std::string, you can either
+ use Twine::str to get the result as an std::string, or
+ could move to a Twine based design.
+
+
isName() should be replaced with comparison
+ against getName() (this is now efficient).
+
+
+
+
The registration interfaces for backend Targets has changed (what was
+previously TargetMachineRegistry). For backend authors, see the Writing An LLVM Backend
+guide. For clients, the notable API changes are:
+
+
TargetMachineRegistry has been renamed
+ to TargetRegistry.
+
+
Clients should move to using the TargetRegistry::lookupTarget()
+ function to find targets.
+
+
@@ -639,15 +1018,15 @@
Intel and AMD machines (IA32, X86-64, AMD64, EMT-64) running Red Hat
-Linux, Fedora Core and FreeBSD (and probably other unix-like systems).
+ Linux, Fedora Core, FreeBSD and AuroraUX (and probably other unix-like
+ systems).
PowerPC and X86-based Mac OS X systems, running 10.3 and above in 32-bit
-and 64-bit modes.
+ and 64-bit modes.
Intel and AMD machines running on Win32 using MinGW libraries (native).
Intel and AMD machines running on Win32 with the Cygwin libraries (limited
support is available for native builds with Visual C++).
Sun UltraSPARC workstations running Solaris 10.
Alpha-based machines running Debian GNU/Linux.
-
Itanium-based (IA64) machines running Linux and HP-UX.
The core LLVM infrastructure uses GNU autoconf to adapt itself
@@ -670,6 +1049,21 @@
href="http://llvm.org/bugs/">LLVM bug database and submit a bug if
there isn't already one.
+
+
The llvm-gcc bootstrap will fail with some versions of binutils (e.g. 2.15)
+ with a message of "Error: can not do 8
+ byte pc-relative relocation" when building C++ code. We intend to
+ fix this on mainline, but a workaround for 2.6 is to upgrade to binutils
+ 2.17 or later.
+
+
LLVM will not correctly compile on Solaris and/or OpenSolaris
+using the stock GCC 3.x.x series 'out the box',
+See: Broken versions of GCC and other tools.
+However, A Modern GCC Build
+for x86/x86-64 has been made available from the third party AuroraUX Project
+that has been meticulously tested for bootstrapping LLVM & Clang.
The MSIL, IA64, Alpha, SPU, MIPS, and PIC16 backends are experimental.
+
The MSIL, Alpha, SPU, MIPS, PIC16, Blackfin, MSP430 and SystemZ backends are
+ experimental.
The llc "-filetype=asm" (the default) is the only
- supported value for this option.
+ supported value for this option. The ELF writer is experimental.
+
The implementation of Andersen's Alias Analysis has many known bugs.
@@ -744,14 +1140,14 @@
+
Support for the Advanced SIMD (Neon) instruction set is still incomplete
+and not well tested. Some features may not work at all, and the code quality
+may be poor in some cases.
Thumb mode works only on ARMv6 or higher processors. On sub-ARMv6
processors, thumb programs can crash or produce wrong
results (PR1388).
Compilation for ARM Linux OABI (old ABI) is supported but not fully tested.
-
There is a bug in QEMU-ARM (<= 0.9.0) which causes it to incorrectly
- execute
-programs compiled with LLVM. Please use more recent versions of QEMU.
The Itanium backend is highly experimental and has a number of known
- issues. We are looking for a maintainer for the Itanium backend. If you
- are interested, please contact the LLVMdev mailing list.
llvm-gcc does not currently support Link-Time
-Optimization on most platforms "out-of-the-box". Please inquire on the
-LLVMdev mailing list if you are interested.
-
The only major language feature of GCC not supported by llvm-gcc is
the __builtin_apply family of builtins. However, some extensions
are only supported on some targets. For example, trampolines are only
@@ -882,7 +1258,8 @@
Fortran support generally works, but there are still several unresolved bugs
- in Bugzilla. Please see the tools/gfortran component for details.
+ in Bugzilla. Please see the
+ tools/gfortran component for details.
@@ -902,16 +1279,16 @@
The Ada front-end fails to bootstrap.
This is due to lack of LLVM support for setjmp/longjmp style
exception handling, which is used internally by the compiler.
-Workaround: configure with --disable-bootstrap.
+Workaround: configure with --disable-bootstrap.
The c380004, c393010
and cxg2021 ACATS tests fail
(c380004 also fails with gcc-4.2 mainline).
If the compiler is built with checks disabled then c393010
causes the compiler to go into an infinite loop, using up all system memory.
Some GCC specific Ada tests continue to crash the compiler.
-
The -E binder option (exception backtraces)
+
The -E binder option (exception backtraces)
does not work and will result in programs
-crashing if an exception is raised. Workaround: do not use -E.
+crashing if an exception is raised. Workaround: do not use -E.
Only discrete types are allowed to start
or finish at a non-byte offset in a record. Workaround: do not pack records
or use representation clauses that result in a field of a non-discrete type
@@ -925,6 +1302,20 @@
The Llvm.Linkage module is broken, and has incorrect values. Only
+Llvm.Linkage.External, Llvm.Linkage.Available_externally, and
+Llvm.Linkage.Link_once will be correct. If you need any of the other linkage
+modes, you'll have to write an external C library in order to expose the
+functionality. This has been fixed in the trunk.
+
+
Additional Information
From gohman at apple.com Tue Oct 13 12:50:43 2009
From: gohman at apple.com (Dan Gohman)
Date: Tue, 13 Oct 2009 17:50:43 -0000
Subject: [llvm-commits] [llvm] r83992 -
/llvm/trunk/lib/Transforms/Scalar/LoopUnswitch.cpp
Message-ID: <200910131750.n9DHohoW012671@zion.cs.uiuc.edu>
Author: djg
Date: Tue Oct 13 12:50:43 2009
New Revision: 83992
URL: http://llvm.org/viewvc/llvm-project?rev=83992&view=rev
Log:
Make LoopUnswitch's cost estimation count Instructions, rather than
BasicBlocks, so that it doesn't blindly procede in the presence of
large individual BasicBlocks. This addresses a class of code-size
expansion problems.
Modified:
llvm/trunk/lib/Transforms/Scalar/LoopUnswitch.cpp
Modified: llvm/trunk/lib/Transforms/Scalar/LoopUnswitch.cpp
URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/lib/Transforms/Scalar/LoopUnswitch.cpp?rev=83992&r1=83991&r2=83992&view=diff
==============================================================================
--- llvm/trunk/lib/Transforms/Scalar/LoopUnswitch.cpp (original)
+++ llvm/trunk/lib/Transforms/Scalar/LoopUnswitch.cpp Tue Oct 13 12:50:43 2009
@@ -56,9 +56,11 @@
STATISTIC(NumTrivial , "Number of unswitches that are trivial");
STATISTIC(NumSimplify, "Number of simplifications of unswitched code");
+// The specific value of 50 here was chosen based only on intuition and a
+// few specific examples.
static cl::opt
Threshold("loop-unswitch-threshold", cl::desc("Max loop size to unswitch"),
- cl::init(10), cl::Hidden);
+ cl::init(50), cl::Hidden);
namespace {
class LoopUnswitch : public LoopPass {
@@ -406,27 +408,13 @@
if (IsTrivialUnswitchCondition(LIC))
return 0;
- // FIXME: This is really overly conservative. However, more liberal
- // estimations have thus far resulted in excessive unswitching, which is bad
- // both in compile time and in code size. This should be replaced once
- // someone figures out how a good estimation.
- return currentLoop->getBlocks().size();
-
+ // FIXME: This is really overly conservative and brain dead.
unsigned Cost = 0;
- // FIXME: this is brain dead. It should take into consideration code
- // shrinkage.
for (Loop::block_iterator I = currentLoop->block_begin(),
E = currentLoop->block_end();
- I != E; ++I) {
- BasicBlock *BB = *I;
- // Do not include empty blocks in the cost calculation. This happen due to
- // loop canonicalization and will be removed.
- if (BB->begin() == BasicBlock::iterator(BB->getTerminator()))
- continue;
-
- // Count basic blocks.
- ++Cost;
- }
+ I != E; ++I)
+ // Count instructions.
+ Cost += (*I)->size();
return Cost;
}
From clattner at apple.com Tue Oct 13 12:53:27 2009
From: clattner at apple.com (Chris Lattner)
Date: Tue, 13 Oct 2009 10:53:27 -0700
Subject: [llvm-commits] [llvm] r83992 -
/llvm/trunk/lib/Transforms/Scalar/LoopUnswitch.cpp
In-Reply-To: <200910131750.n9DHohoW012671@zion.cs.uiuc.edu>
References: <200910131750.n9DHohoW012671@zion.cs.uiuc.edu>
Message-ID:
On Oct 13, 2009, at 10:50 AM, Dan Gohman wrote:
> Author: djg
> Date: Tue Oct 13 12:50:43 2009
> New Revision: 83992
>
> URL: http://llvm.org/viewvc/llvm-project?rev=83992&view=rev
> Log:
> Make LoopUnswitch's cost estimation count Instructions, rather than
> BasicBlocks, so that it doesn't blindly procede in the presence of
> large individual BasicBlocks. This addresses a class of code-size
> expansion problems.
This should use the heuristic the inliner etc has. In particular it
is important that presence of debug intrinsics not affect the cost.
-Chris
>
> Modified:
> llvm/trunk/lib/Transforms/Scalar/LoopUnswitch.cpp
>
> Modified: llvm/trunk/lib/Transforms/Scalar/LoopUnswitch.cpp
> URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/lib/Transforms/Scalar/LoopUnswitch.cpp?rev=83992&r1=83991&r2=83992&view=diff
>
> =
> =
> =
> =
> =
> =
> =
> =
> ======================================================================
> --- llvm/trunk/lib/Transforms/Scalar/LoopUnswitch.cpp (original)
> +++ llvm/trunk/lib/Transforms/Scalar/LoopUnswitch.cpp Tue Oct 13
> 12:50:43 2009
> @@ -56,9 +56,11 @@
> STATISTIC(NumTrivial , "Number of unswitches that are trivial");
> STATISTIC(NumSimplify, "Number of simplifications of unswitched
> code");
>
> +// The specific value of 50 here was chosen based only on intuition
> and a
> +// few specific examples.
> static cl::opt
> Threshold("loop-unswitch-threshold", cl::desc("Max loop size to
> unswitch"),
> - cl::init(10), cl::Hidden);
> + cl::init(50), cl::Hidden);
>
> namespace {
> class LoopUnswitch : public LoopPass {
> @@ -406,27 +408,13 @@
> if (IsTrivialUnswitchCondition(LIC))
> return 0;
>
> - // FIXME: This is really overly conservative. However, more
> liberal
> - // estimations have thus far resulted in excessive unswitching,
> which is bad
> - // both in compile time and in code size. This should be
> replaced once
> - // someone figures out how a good estimation.
> - return currentLoop->getBlocks().size();
> -
> + // FIXME: This is really overly conservative and brain dead.
> unsigned Cost = 0;
> - // FIXME: this is brain dead. It should take into consideration
> code
> - // shrinkage.
> for (Loop::block_iterator I = currentLoop->block_begin(),
> E = currentLoop->block_end();
> - I != E; ++I) {
> - BasicBlock *BB = *I;
> - // Do not include empty blocks in the cost calculation. This
> happen due to
> - // loop canonicalization and will be removed.
> - if (BB->begin() == BasicBlock::iterator(BB->getTerminator()))
> - continue;
> -
> - // Count basic blocks.
> - ++Cost;
> - }
> + I != E; ++I)
> + // Count instructions.
> + Cost += (*I)->size();
>
> return Cost;
> }
>
>
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
From sabre at nondot.org Tue Oct 13 13:08:22 2009
From: sabre at nondot.org (Chris Lattner)
Date: Tue, 13 Oct 2009 18:08:22 -0000
Subject: [llvm-commits] [llvm] r83994 - in
/llvm/trunk/test/Transforms/SimplifyCFG: InvokeEliminate.ll
invoke_unwind.ll
Message-ID: <200910131808.n9DI8MQq013486@zion.cs.uiuc.edu>
Author: lattner
Date: Tue Oct 13 13:08:21 2009
New Revision: 83994
URL: http://llvm.org/viewvc/llvm-project?rev=83994&view=rev
Log:
rename test
Added:
llvm/trunk/test/Transforms/SimplifyCFG/invoke_unwind.ll
- copied unchanged from r83936, llvm/trunk/test/Transforms/SimplifyCFG/InvokeEliminate.ll
Removed:
llvm/trunk/test/Transforms/SimplifyCFG/InvokeEliminate.ll
Removed: llvm/trunk/test/Transforms/SimplifyCFG/InvokeEliminate.ll
URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/test/Transforms/SimplifyCFG/InvokeEliminate.ll?rev=83993&view=auto
==============================================================================
--- llvm/trunk/test/Transforms/SimplifyCFG/InvokeEliminate.ll (original)
+++ llvm/trunk/test/Transforms/SimplifyCFG/InvokeEliminate.ll (removed)
@@ -1,18 +0,0 @@
-; This testcase checks to see if the simplifycfg pass is converting invoke
-; instructions to call instructions if the handler just rethrows the exception.
-
-; If this test is successful, the function should be reduced to 'call; ret'
-
-; RUN: opt < %s -simplifycfg -S | \
-; RUN: not egrep {\\(invoke\\)|\\(br\\)}
-
-declare void @bar()
-
-define i32 @test() {
- invoke void @bar( )
- to label %Ok unwind label %Rethrow
-Ok: ; preds = %0
- ret i32 0
-Rethrow: ; preds = %0
- unwind
-}
From sabre at nondot.org Tue Oct 13 13:10:06 2009
From: sabre at nondot.org (Chris Lattner)
Date: Tue, 13 Oct 2009 18:10:06 -0000
Subject: [llvm-commits] [llvm] r83995 -
/llvm/trunk/test/Transforms/SimplifyCFG/invoke_unwind.ll
Message-ID: <200910131810.n9DIA6TU013598@zion.cs.uiuc.edu>
Author: lattner
Date: Tue Oct 13 13:10:05 2009
New Revision: 83995
URL: http://llvm.org/viewvc/llvm-project?rev=83995&view=rev
Log:
convert to filecheck
Modified:
llvm/trunk/test/Transforms/SimplifyCFG/invoke_unwind.ll
Modified: llvm/trunk/test/Transforms/SimplifyCFG/invoke_unwind.ll
URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/test/Transforms/SimplifyCFG/invoke_unwind.ll?rev=83995&r1=83994&r2=83995&view=diff
==============================================================================
--- llvm/trunk/test/Transforms/SimplifyCFG/invoke_unwind.ll (original)
+++ llvm/trunk/test/Transforms/SimplifyCFG/invoke_unwind.ll Tue Oct 13 13:10:05 2009
@@ -1,14 +1,14 @@
; This testcase checks to see if the simplifycfg pass is converting invoke
; instructions to call instructions if the handler just rethrows the exception.
-; If this test is successful, the function should be reduced to 'call; ret'
-
-; RUN: opt < %s -simplifycfg -S | \
-; RUN: not egrep {\\(invoke\\)|\\(br\\)}
+; RUN: opt < %s -simplifycfg -S | FileCheck %s
declare void @bar()
-define i32 @test() {
+define i32 @test1() {
+; CHECK: @test1
+; CHECK-NEXT: call void @bar()
+; CHECK-NEXT: ret i32 0
invoke void @bar( )
to label %Ok unwind label %Rethrow
Ok: ; preds = %0
From sabre at nondot.org Tue Oct 13 13:13:06 2009
From: sabre at nondot.org (Chris Lattner)
Date: Tue, 13 Oct 2009 18:13:06 -0000
Subject: [llvm-commits] [llvm] r83996 - in /llvm/trunk:
lib/Transforms/Utils/SimplifyCFG.cpp
test/Transforms/SimplifyCFG/invoke_unwind.ll
Message-ID: <200910131813.n9DID6Cb013722@zion.cs.uiuc.edu>
Author: lattner
Date: Tue Oct 13 13:13:05 2009
New Revision: 83996
URL: http://llvm.org/viewvc/llvm-project?rev=83996&view=rev
Log:
change simplifycfg to not duplicate 'unwind' instructions. Hopefully
this will increase the likelihood of common code getting sunk towards
the unwind.
Modified:
llvm/trunk/lib/Transforms/Utils/SimplifyCFG.cpp
llvm/trunk/test/Transforms/SimplifyCFG/invoke_unwind.ll
Modified: llvm/trunk/lib/Transforms/Utils/SimplifyCFG.cpp
URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/lib/Transforms/Utils/SimplifyCFG.cpp?rev=83996&r1=83995&r2=83996&view=diff
==============================================================================
--- llvm/trunk/lib/Transforms/Utils/SimplifyCFG.cpp (original)
+++ llvm/trunk/lib/Transforms/Utils/SimplifyCFG.cpp Tue Oct 13 13:13:05 2009
@@ -1860,33 +1860,26 @@
} else if (isa(BB->begin())) {
// Check to see if the first instruction in this block is just an unwind.
// If so, replace any invoke instructions which use this as an exception
- // destination with call instructions, and any unconditional branch
- // predecessor with an unwind.
+ // destination with call instructions.
//
SmallVector Preds(pred_begin(BB), pred_end(BB));
while (!Preds.empty()) {
BasicBlock *Pred = Preds.back();
- if (BranchInst *BI = dyn_cast(Pred->getTerminator())) {
- if (BI->isUnconditional()) {
- Pred->getInstList().pop_back(); // nuke uncond branch
- new UnwindInst(Pred->getContext(), Pred); // Use unwind.
- Changed = true;
- }
- } else if (InvokeInst *II = dyn_cast(Pred->getTerminator()))
+ if (InvokeInst *II = dyn_cast(Pred->getTerminator()))
if (II->getUnwindDest() == BB) {
// Insert a new branch instruction before the invoke, because this
- // is now a fall through...
+ // is now a fall through.
BranchInst *BI = BranchInst::Create(II->getNormalDest(), II);
Pred->getInstList().remove(II); // Take out of symbol table
- // Insert the call now...
+ // Insert the call now.
SmallVector Args(II->op_begin()+3, II->op_end());
CallInst *CI = CallInst::Create(II->getCalledValue(),
Args.begin(), Args.end(),
II->getName(), BI);
CI->setCallingConv(II->getCallingConv());
CI->setAttributes(II->getAttributes());
- // If the invoke produced a value, the Call now does instead
+ // If the invoke produced a value, the Call now does instead.
II->replaceAllUsesWith(CI);
delete II;
Changed = true;
Modified: llvm/trunk/test/Transforms/SimplifyCFG/invoke_unwind.ll
URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/test/Transforms/SimplifyCFG/invoke_unwind.ll?rev=83996&r1=83995&r2=83996&view=diff
==============================================================================
--- llvm/trunk/test/Transforms/SimplifyCFG/invoke_unwind.ll (original)
+++ llvm/trunk/test/Transforms/SimplifyCFG/invoke_unwind.ll Tue Oct 13 13:13:05 2009
@@ -1,10 +1,9 @@
-; This testcase checks to see if the simplifycfg pass is converting invoke
-; instructions to call instructions if the handler just rethrows the exception.
-
; RUN: opt < %s -simplifycfg -S | FileCheck %s
declare void @bar()
+; This testcase checks to see if the simplifycfg pass is converting invoke
+; instructions to call instructions if the handler just rethrows the exception.
define i32 @test1() {
; CHECK: @test1
; CHECK-NEXT: call void @bar()
@@ -16,3 +15,19 @@
Rethrow: ; preds = %0
unwind
}
+
+
+; Verify that simplifycfg isn't duplicating 'unwind' instructions. Doing this
+; is bad because it discourages commoning.
+define i32 @test2(i1 %c) {
+; CHECK: @test2
+; CHECK: T:
+; CHECK-NEXT: call void @bar()
+; CHECK-NEXT: br label %F
+ br i1 %c, label %T, label %F
+T:
+ call void @bar()
+ br label %F
+F:
+ unwind
+}
From gohman at apple.com Tue Oct 13 13:24:11 2009
From: gohman at apple.com (Dan Gohman)
Date: Tue, 13 Oct 2009 18:24:11 -0000
Subject: [llvm-commits] [llvm] r83997 - in /llvm/trunk:
include/llvm/Transforms/Utils/InlineCost.h
lib/Transforms/Utils/InlineCost.cpp
Message-ID: <200910131824.n9DIOBJu014153@zion.cs.uiuc.edu>
Author: djg
Date: Tue Oct 13 13:24:11 2009
New Revision: 83997
URL: http://llvm.org/viewvc/llvm-project?rev=83997&view=rev
Log:
Start refactoring the inline cost estimation code so that it can be used
for purposes other than inlining.
Modified:
llvm/trunk/include/llvm/Transforms/Utils/InlineCost.h
llvm/trunk/lib/Transforms/Utils/InlineCost.cpp
Modified: llvm/trunk/include/llvm/Transforms/Utils/InlineCost.h
URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/include/llvm/Transforms/Utils/InlineCost.h?rev=83997&r1=83996&r2=83997&view=diff
==============================================================================
--- llvm/trunk/include/llvm/Transforms/Utils/InlineCost.h (original)
+++ llvm/trunk/include/llvm/Transforms/Utils/InlineCost.h Tue Oct 13 13:24:11 2009
@@ -23,6 +23,7 @@
class Value;
class Function;
+ class BasicBlock;
class CallSite;
template
class SmallPtrSet;
@@ -96,9 +97,9 @@
: ConstantWeight(CWeight), AllocaWeight(AWeight) {}
};
- // FunctionInfo - For each function, calculate the size of it in blocks and
- // instructions.
- struct FunctionInfo {
+ // RegionInfo - Calculate size and a few related metrics for a set of
+ // basic blocks.
+ struct RegionInfo {
/// NeverInline - True if this callee should never be inlined into a
/// caller.
bool NeverInline;
@@ -115,17 +116,24 @@
/// kernels.
unsigned NumVectorInsts;
+ /// NumRets - Keep track of how many Ret instructions the block contains.
+ unsigned NumRets;
+
/// ArgumentWeights - Each formal argument of the function is inspected to
/// see if it is used in any contexts where making it a constant or alloca
/// would reduce the code size. If so, we add some value to the argument
/// entry here.
std::vector ArgumentWeights;
- FunctionInfo() : NeverInline(false), usesDynamicAlloca(false), NumInsts(0),
- NumBlocks(0), NumVectorInsts(0) {}
+ RegionInfo() : NeverInline(false), usesDynamicAlloca(false), NumInsts(0),
+ NumBlocks(0), NumVectorInsts(0), NumRets(0) {}
- /// analyzeFunction - Fill in the current structure with information
- /// gleaned from the specified function.
+ /// analyzeBasicBlock - Add information about the specified basic block
+ /// to the current structure.
+ void analyzeBasicBlock(const BasicBlock *BB);
+
+ /// analyzeFunction - Add information about the specified function
+ /// to the current structure.
void analyzeFunction(Function *F);
/// CountCodeReductionForConstant - Figure out an approximation for how
@@ -140,7 +148,7 @@
unsigned CountCodeReductionForAlloca(Value *V);
};
- std::map CachedFunctionInfo;
+ std::map CachedFunctionInfo;
public:
Modified: llvm/trunk/lib/Transforms/Utils/InlineCost.cpp
URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/lib/Transforms/Utils/InlineCost.cpp?rev=83997&r1=83996&r2=83997&view=diff
==============================================================================
--- llvm/trunk/lib/Transforms/Utils/InlineCost.cpp (original)
+++ llvm/trunk/lib/Transforms/Utils/InlineCost.cpp Tue Oct 13 13:24:11 2009
@@ -21,7 +21,7 @@
// CountCodeReductionForConstant - Figure out an approximation for how many
// instructions will be constant folded if the specified value is constant.
//
-unsigned InlineCostAnalyzer::FunctionInfo::
+unsigned InlineCostAnalyzer::RegionInfo::
CountCodeReductionForConstant(Value *V) {
unsigned Reduction = 0;
for (Value::use_iterator UI = V->use_begin(), E = V->use_end(); UI != E; ++UI)
@@ -77,7 +77,7 @@
// the function will be if it is inlined into a context where an argument
// becomes an alloca.
//
-unsigned InlineCostAnalyzer::FunctionInfo::
+unsigned InlineCostAnalyzer::RegionInfo::
CountCodeReductionForAlloca(Value *V) {
if (!isa(V->getType())) return 0; // Not a pointer
unsigned Reduction = 0;
@@ -99,85 +99,85 @@
return Reduction;
}
-/// analyzeFunction - Fill in the current structure with information gleaned
-/// from the specified function.
-void InlineCostAnalyzer::FunctionInfo::analyzeFunction(Function *F) {
- unsigned NumInsts = 0, NumBlocks = 0, NumVectorInsts = 0, NumRets = 0;
-
- // Look at the size of the callee. Each basic block counts as 20 units, and
- // each instruction counts as 5.
- for (Function::const_iterator BB = F->begin(), E = F->end(); BB != E; ++BB) {
- for (BasicBlock::const_iterator II = BB->begin(), E = BB->end();
- II != E; ++II) {
- if (isa(II)) continue; // PHI nodes don't count.
-
- // Special handling for calls.
- if (isa(II) || isa(II)) {
- if (isa(II))
- continue; // Debug intrinsics don't count as size.
-
- CallSite CS = CallSite::get(const_cast(&*II));
-
- // If this function contains a call to setjmp or _setjmp, never inline
- // it. This is a hack because we depend on the user marking their local
- // variables as volatile if they are live across a setjmp call, and they
- // probably won't do this in callers.
- if (Function *F = CS.getCalledFunction())
- if (F->isDeclaration() &&
- (F->getName() == "setjmp" || F->getName() == "_setjmp")) {
- NeverInline = true;
- return;
- }
-
- // Calls often compile into many machine instructions. Bump up their
- // cost to reflect this.
- if (!isa(II))
- NumInsts += InlineConstants::CallPenalty;
- }
+/// analyzeBasicBlock - Fill in the current structure with information gleaned
+/// from the specified block.
+void InlineCostAnalyzer::RegionInfo::analyzeBasicBlock(const BasicBlock *BB) {
+ ++NumBlocks;
+
+ for (BasicBlock::const_iterator II = BB->begin(), E = BB->end();
+ II != E; ++II) {
+ if (isa(II)) continue; // PHI nodes don't count.
+
+ // Special handling for calls.
+ if (isa(II) || isa(II)) {
+ if (isa(II))
+ continue; // Debug intrinsics don't count as size.
- // These, too, are calls.
- if (isa(II) || isa(II))
- NumInsts += InlineConstants::CallPenalty;
-
- if (const AllocaInst *AI = dyn_cast(II)) {
- if (!AI->isStaticAlloca())
- this->usesDynamicAlloca = true;
- }
-
- if (isa(II) || isa(II->getType()))
- ++NumVectorInsts;
+ CallSite CS = CallSite::get(const_cast(&*II));
- // Noop casts, including ptr <-> int, don't count.
- if (const CastInst *CI = dyn_cast(II)) {
- if (CI->isLosslessCast() || isa(CI) ||
- isa(CI))
- continue;
- } else if (const GetElementPtrInst *GEPI =
- dyn_cast(II)) {
- // If a GEP has all constant indices, it will probably be folded with
- // a load/store.
- if (GEPI->hasAllConstantIndices())
- continue;
- }
+ // If this function contains a call to setjmp or _setjmp, never inline
+ // it. This is a hack because we depend on the user marking their local
+ // variables as volatile if they are live across a setjmp call, and they
+ // probably won't do this in callers.
+ if (Function *F = CS.getCalledFunction())
+ if (F->isDeclaration() &&
+ (F->getName() == "setjmp" || F->getName() == "_setjmp")) {
+ NeverInline = true;
+ return;
+ }
- if (isa(II))
- ++NumRets;
-
- ++NumInsts;
+ // Calls often compile into many machine instructions. Bump up their
+ // cost to reflect this.
+ if (!isa(II))
+ NumInsts += InlineConstants::CallPenalty;
+ }
+
+ // These, too, are calls.
+ if (isa(II) || isa(II))
+ NumInsts += InlineConstants::CallPenalty;
+
+ if (const AllocaInst *AI = dyn_cast(II)) {
+ if (!AI->isStaticAlloca())
+ this->usesDynamicAlloca = true;
}
- ++NumBlocks;
+ if (isa(II) || isa(II->getType()))
+ ++NumVectorInsts;
+
+ // Noop casts, including ptr <-> int, don't count.
+ if (const CastInst *CI = dyn_cast(II)) {
+ if (CI->isLosslessCast() || isa(CI) ||
+ isa(CI))
+ continue;
+ } else if (const GetElementPtrInst *GEPI =
+ dyn_cast(II)) {
+ // If a GEP has all constant indices, it will probably be folded with
+ // a load/store.
+ if (GEPI->hasAllConstantIndices())
+ continue;
+ }
+
+ if (isa(II))
+ ++NumRets;
+
+ ++NumInsts;
}
+}
+
+/// analyzeFunction - Fill in the current structure with information gleaned
+/// from the specified function.
+void InlineCostAnalyzer::RegionInfo::analyzeFunction(Function *F) {
+ // Look at the size of the callee. Each basic block counts as 20 units, and
+ // each instruction counts as 5.
+ for (Function::const_iterator BB = F->begin(), E = F->end(); BB != E; ++BB)
+ analyzeBasicBlock(&*BB);
// A function with exactly one return has it removed during the inlining
// process (see InlineFunction), so don't count it.
+ // FIXME: This knowledge should really be encoded outside of RegionInfo.
if (NumRets==1)
--NumInsts;
- this->NumBlocks = NumBlocks;
- this->NumInsts = NumInsts;
- this->NumVectorInsts = NumVectorInsts;
-
// Check out all of the arguments to the function, figuring out how much
// code can be eliminated if one of the arguments is a constant.
for (Function::arg_iterator I = F->arg_begin(), E = F->arg_end(); I != E; ++I)
@@ -229,7 +229,7 @@
InlineCost += InlineConstants::NoreturnPenalty;
// Get information about the callee...
- FunctionInfo &CalleeFI = CachedFunctionInfo[Callee];
+ RegionInfo &CalleeFI = CachedFunctionInfo[Callee];
// If we haven't calculated this information yet, do so now.
if (CalleeFI.NumBlocks == 0)
@@ -240,7 +240,7 @@
return InlineCost::getNever();
// FIXME: It would be nice to kill off CalleeFI.NeverInline. Then we
- // could move this up and avoid computing the FunctionInfo for
+ // could move this up and avoid computing the RegionInfo for
// things we are going to just return always inline for. This
// requires handling setjmp somewhere else, however.
if (!Callee->isDeclaration() && Callee->hasFnAttr(Attribute::AlwaysInline))
@@ -248,7 +248,7 @@
if (CalleeFI.usesDynamicAlloca) {
// Get infomation about the caller...
- FunctionInfo &CallerFI = CachedFunctionInfo[Caller];
+ RegionInfo &CallerFI = CachedFunctionInfo[Caller];
// If we haven't calculated this information yet, do so now.
if (CallerFI.NumBlocks == 0)
@@ -316,7 +316,7 @@
Function *Callee = CS.getCalledFunction();
// Get information about the callee...
- FunctionInfo &CalleeFI = CachedFunctionInfo[Callee];
+ RegionInfo &CalleeFI = CachedFunctionInfo[Callee];
// If we haven't calculated this information yet, do so now.
if (CalleeFI.NumBlocks == 0)
From gohman at apple.com Tue Oct 13 13:30:07 2009
From: gohman at apple.com (Dan Gohman)
Date: Tue, 13 Oct 2009 18:30:07 -0000
Subject: [llvm-commits] [llvm] r83998 - in /llvm/trunk:
include/llvm/Analysis/InlineCost.h
include/llvm/Transforms/Utils/BasicInliner.h
include/llvm/Transforms/Utils/InlineCost.h lib/Analysis/InlineCost.cpp
lib/Transforms/IPO/InlineAlways.cpp lib/Transforms/IPO/InlineSimple.cpp
lib/Transforms/IPO/Inliner.cpp
Message-ID: <200910131830.n9DIU8BE014408@zion.cs.uiuc.edu>
Author: djg
Date: Tue Oct 13 13:30:07 2009
New Revision: 83998
URL: http://llvm.org/viewvc/llvm-project?rev=83998&view=rev
Log:
Move the InlineCost code from Transforms/Utils to Analysis.
Added:
llvm/trunk/include/llvm/Analysis/InlineCost.h
- copied, changed from r83997, llvm/trunk/include/llvm/Transforms/Utils/InlineCost.h
llvm/trunk/lib/Analysis/InlineCost.cpp
- copied, changed from r83997, llvm/trunk/lib/Transforms/Utils/InlineCost.cpp
Removed:
llvm/trunk/include/llvm/Transforms/Utils/InlineCost.h
Modified:
llvm/trunk/include/llvm/Transforms/Utils/BasicInliner.h
llvm/trunk/lib/Transforms/IPO/InlineAlways.cpp
llvm/trunk/lib/Transforms/IPO/InlineSimple.cpp
llvm/trunk/lib/Transforms/IPO/Inliner.cpp
Copied: llvm/trunk/include/llvm/Analysis/InlineCost.h (from r83997, llvm/trunk/include/llvm/Transforms/Utils/InlineCost.h)
URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/include/llvm/Analysis/InlineCost.h?p2=llvm/trunk/include/llvm/Analysis/InlineCost.h&p1=llvm/trunk/include/llvm/Transforms/Utils/InlineCost.h&r1=83997&r2=83998&rev=83998&view=diff
==============================================================================
--- llvm/trunk/include/llvm/Transforms/Utils/InlineCost.h (original)
+++ llvm/trunk/include/llvm/Analysis/InlineCost.h Tue Oct 13 13:30:07 2009
@@ -11,8 +11,8 @@
//
//===----------------------------------------------------------------------===//
-#ifndef LLVM_TRANSFORMS_UTILS_INLINECOST_H
-#define LLVM_TRANSFORMS_UTILS_INLINECOST_H
+#ifndef LLVM_ANALYSIS_INLINECOST_H
+#define LLVM_ANALYSIS_INLINECOST_H
#include
#include
Modified: llvm/trunk/include/llvm/Transforms/Utils/BasicInliner.h
URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/include/llvm/Transforms/Utils/BasicInliner.h?rev=83998&r1=83997&r2=83998&view=diff
==============================================================================
--- llvm/trunk/include/llvm/Transforms/Utils/BasicInliner.h (original)
+++ llvm/trunk/include/llvm/Transforms/Utils/BasicInliner.h Tue Oct 13 13:30:07 2009
@@ -15,7 +15,7 @@
#ifndef BASICINLINER_H
#define BASICINLINER_H
-#include "llvm/Transforms/Utils/InlineCost.h"
+#include "llvm/Analysis/InlineCost.h"
namespace llvm {
Removed: llvm/trunk/include/llvm/Transforms/Utils/InlineCost.h
URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/include/llvm/Transforms/Utils/InlineCost.h?rev=83997&view=auto
==============================================================================
--- llvm/trunk/include/llvm/Transforms/Utils/InlineCost.h (original)
+++ llvm/trunk/include/llvm/Transforms/Utils/InlineCost.h (removed)
@@ -1,172 +0,0 @@
-//===- InlineCost.cpp - Cost analysis for inliner ---------------*- C++ -*-===//
-//
-// The LLVM Compiler Infrastructure
-//
-// This file is distributed under the University of Illinois Open Source
-// License. See LICENSE.TXT for details.
-//
-//===----------------------------------------------------------------------===//
-//
-// This file implements heuristics for inlining decisions.
-//
-//===----------------------------------------------------------------------===//
-
-#ifndef LLVM_TRANSFORMS_UTILS_INLINECOST_H
-#define LLVM_TRANSFORMS_UTILS_INLINECOST_H
-
-#include
-#include
-#include