From grosser at fim.uni-passau.de Mon Jul 4 00:26:17 2011
From: grosser at fim.uni-passau.de (Tobias Grosser)
Date: Mon, 04 Jul 2011 00:26:17 -0500
Subject: [llvm-commits] [PATCH] SuccIterator on bbs without terminator
insts
In-Reply-To: <4E1106A7.10101@mxc.ca>
References: <4E10F310.4060705@fim.uni-passau.de> <4E1106A7.10101@mxc.ca>
Message-ID: <4E114EF9.8080105@fim.uni-passau.de>
On 07/03/2011 07:17 PM, Nick Lewycky wrote:
> Tobias Grosser wrote:
>> Hi,
>>
>> this patch removes the assert, that triggers if SuccIterator is
>> constructed for a basic block without a terminator instruction. Instead
>> of triggering an assert a succ_end() iterator is returned. This models a
>> basic block with zero successors and allows us to use F->viewCFG() on
>> incompletely constructed functions.
>>
>> OK to commit?
>
> Intuitively no, because all basic blocks are required to have
> terminators. But I suspect you ran into this for a reason, and tools
> like succ_begin/end() may not be able to assume that the CFG is valid at
> any point in time because the IR is being modified. Could you explain
> more about what you were doing which triggered this?
It's pretty easy.
In Polly we modify the CFG by adding some additional basic blocks
(actually a branch that contains an optimized code path). Once in a
while (because of a bug in Polly or somewhere in LLVM) I have a failing
test case. My first step to investigate a bug is to put a breakpoint at
the place in the code where I suspect the bug (or an assert triggered).
My next step is to call F->viewCFG() to see the current state of the
CFG. Unfortunately this almost never works, as the CFG is at this point
not yet fully constructed and consequently the above assert triggers.
In general I believe for debugging it would be very helpful if
F->viewCFG() would already work during the construction of the CFG.
> Would it be
> difficult to avoid calling succ_begin() on malformed basic blocks?
Yes. The problem is viewCFG() and in general the Graph printing
infrastructure use the normal GraphTraits description of the CFG, which
again calls the succ_begin/end() functions. Hence, viewCFG() only works
on incomplete functions/basic blocks if the normal GraphTraits and the
succ_begin/end() iterators can handle incomplete basic blocks. This is
currently not the case (because of the assert).
I personally see no problem removing the assert, because conceptually a
basic block without any terminator is just a basic block with zero
successors. There is also no need to enforce the required form of the
LLVM-IR through the succ_begin()/end() iterators, as we have a dedicated
verification pass for this.
Cheers
Tobi
From x.tong at utoronto.ca Mon Jul 4 10:14:12 2011
From: x.tong at utoronto.ca (Xin Tong Utoronto)
Date: Mon, 4 Jul 2011 11:14:12 -0400
Subject: [llvm-commits] [llvm jit adaptive-compilation] : Adaptive
compilation framework x86 Patch
Message-ID:
Hi All
This patch is intended to provide support for LLVM JIT adaptive compilation
on x86 platforms. The implementation of the adaptive compilation framework
is one of the Google Summer of Code 2011 projects (
http://www.google-melange.com/gsoc/project/google/gsoc2011/timexerox/8001).
The patch is created against the LLVM branch below. It is currently
reviewed by Eric Christoper at Apple and will be applied to the LLVM branch (
https://echristo@
llvm.org/svn/llvm-project/llvm/branches/GSoC/adaptive-compilation). But more
eyes are definitely welcome. Originally, the LLVM adaptive compilation
framework was intended to be applied to LLVM head stream, but due to
concerns regarding the upcoming major changes on ExecutionEngine and MCJIT.
it is now worked in a branch and hopefully applied to the head stream once
the MCJIT changes have been completed.
*
*
*This patch involves changes to *
include/llvm/Target/TargetJITInfo.h
lib/Target/X86/X86JITInfo.h
lib/Target/X86/X86JITInfo.cpp
lib/Target/ARM/ARMJITInfo.h
lib/Target/ARM/ARMJITInfo.cpp
lib/Target/PowerPC/PPCJITInfo.h
lib/Target/PowerPC/PPCJITInfo.cpp
lib/ExecutionEngine/JIT/JITEmitter.cpp
lib/ExecutionEngine/JIT/JIT.h
lib/ExecutionEngine/JIT/JIT.cpp
*This was tested on x86 and x86-64 under Ubuntu with*
*
*
llvm test-suite
*There were no regressions for the O0 - O3 JIT compilation. Additionally,
adaptive compilation currently gives better performance numbers than O1 - O3
as shown.*
lli -O0
Total Time is 1068.37
lli -O1
Total Time is 1395.68
lli -O2
Total Time is 1394.81
lli -O3
Total Time is 1395.76
lli -adaptive-comp
Total Time is 1119.23
Thank You
Xin Tong
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/llvm-commits/attachments/20110704/2631243a/attachment.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: x86_adaptivecomp.patch
Type: application/octet-stream
Size: 26515 bytes
Desc: not available
Url : http://lists.cs.uiuc.edu/pipermail/llvm-commits/attachments/20110704/2631243a/attachment.obj
From rdivacky at freebsd.org Mon Jul 4 10:42:45 2011
From: rdivacky at freebsd.org (Roman Divacky)
Date: Mon, 04 Jul 2011 15:42:45 -0000
Subject: [llvm-commits] [llvm] r134376 -
/llvm/trunk/lib/Target/PowerPC/PPCISelLowering.cpp
Message-ID: <20110704154245.591582A6C12C@llvm.org>
Author: rdivacky
Date: Mon Jul 4 10:42:45 2011
New Revision: 134376
URL: http://llvm.org/viewvc/llvm-project?rev=134376&view=rev
Log:
Remove accidentaly left node from previous iteration of the patch.
Noticed by Benjamin Kramer!
Modified:
llvm/trunk/lib/Target/PowerPC/PPCISelLowering.cpp
Modified: llvm/trunk/lib/Target/PowerPC/PPCISelLowering.cpp
URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/lib/Target/PowerPC/PPCISelLowering.cpp?rev=134376&r1=134375&r2=134376&view=diff
==============================================================================
--- llvm/trunk/lib/Target/PowerPC/PPCISelLowering.cpp (original)
+++ llvm/trunk/lib/Target/PowerPC/PPCISelLowering.cpp Mon Jul 4 10:42:45 2011
@@ -1321,9 +1321,6 @@
SDValue CC = DAG.getSetCC(dl, MVT::i32, VT.isInteger() ? GprIndex : FprIndex,
DAG.getConstant(8, MVT::i32), ISD::SETLT);
- SDValue Area = DAG.getNode(ISD::SELECT, dl, MVT::i32, CC, RegSaveArea,
- OverflowArea);
-
// adjustment constant gpr_index * 4/8
SDValue RegConstant = DAG.getNode(ISD::MUL, dl, MVT::i32,
VT.isInteger() ? GprIndex : FprIndex,
From x.tong at utoronto.ca Mon Jul 4 10:58:05 2011
From: x.tong at utoronto.ca (Xin Tong Utoronto)
Date: Mon, 4 Jul 2011 11:58:05 -0400
Subject: [llvm-commits] [llvm jit adaptive-compilation] : Adaptive
compilation framework x86 Patch
In-Reply-To: <4e11d99c.8521e70a.2556.2dfeSMTPIN_ADDED@mx.google.com>
References:
<4e11d99c.8521e70a.2556.2dfeSMTPIN_ADDED@mx.google.com>
Message-ID:
The original numbers are the same as what are given here. As the lli -O0 -
O3 is virtually the same as before if adaptive compilation is not enabled.
Thanks
Xin
On Mon, Jul 4, 2011 at 11:17 AM, James Molloy wrote:
> Hi Xin,****
>
> ** **
>
> What were the original numbers before adaptive compilation?****
>
> ** **
>
> Cheers,****
>
> ** **
>
> James****
>
> ** **
>
> *From:* llvm-commits-bounces at cs.uiuc.edu [mailto:
> llvm-commits-bounces at cs.uiuc.edu] *On Behalf Of *Xin Tong Utoronto
> *Sent:* 04 July 2011 16:14
> *To:* llvm-commits at cs.uiuc.edu
> *Subject:* [llvm-commits] [llvm jit adaptive-compilation] : Adaptive
> compilation framework x86 Patch****
>
> ** **
>
> Hi All****
>
> ****
>
> This patch is intended to provide support for LLVM JIT adaptive compilation
> on x86 platforms. The implementation of the adaptive compilation framework
> is one of the Google Summer of Code 2011 projects (
> http://www.google-melange.com/gsoc/project/google/gsoc2011/timexerox/8001).
> The patch is created against the LLVM branch below. It is currently
> reviewed by Eric Christoper at Apple and will be applied to the LLVM branch (
> https://echristo@
> llvm.org/svn/llvm-project/llvm/branches/GSoC/adaptive-compilation). But
> more eyes are definitely welcome. Originally, the LLVM adaptive compilation
> framework was intended to be applied to LLVM head stream, but due to
> concerns regarding the upcoming major changes on ExecutionEngine and MCJIT.
> it is now worked in a branch and hopefully applied to the head stream once
> the MCJIT changes have been completed.****
>
> ** **
>
> *This patch involves changes to *****
>
> ****
>
> include/llvm/Target/TargetJITInfo.h****
>
> lib/Target/X86/X86JITInfo.h****
>
> lib/Target/X86/X86JITInfo.cpp****
>
> lib/Target/ARM/ARMJITInfo.h****
>
> lib/Target/ARM/ARMJITInfo.cpp****
>
> lib/Target/PowerPC/PPCJITInfo.h****
>
> lib/Target/PowerPC/PPCJITInfo.cpp****
>
> lib/ExecutionEngine/JIT/JITEmitter.cpp****
>
> lib/ExecutionEngine/JIT/JIT.h****
>
> lib/ExecutionEngine/JIT/JIT.cpp****
>
> ****
>
> *This was tested on x86 and x86-64 under Ubuntu with*****
>
> ** **
>
> llvm test-suite****
>
> ****
>
> *There were no regressions for the O0 - O3 JIT compilation. Additionally,
> adaptive compilation currently gives better performance numbers than O1 - O3
> as shown.*****
>
> ****
>
> lli -O0****
>
> Total Time is 1068.37****
>
> lli -O1****
>
> Total Time is 1395.68****
>
> ****
>
> lli -O2****
>
> Total Time is 1394.81****
>
> ****
>
> lli -O3****
>
> Total Time is 1395.76****
>
> ****
>
> lli -adaptive-comp****
>
> Total Time is 1119.23****
>
> ****
>
> ****
>
> Thank You****
>
> Xin Tong ****
>
--
Kind Regards
Xin Tong
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/llvm-commits/attachments/20110704/af22b51a/attachment.html
From james.molloy at arm.com Mon Jul 4 10:17:36 2011
From: james.molloy at arm.com (James Molloy)
Date: Mon, 4 Jul 2011 16:17:36 +0100
Subject: [llvm-commits] [llvm jit adaptive-compilation] :
Adaptive compilation framework x86 Patch
In-Reply-To:
References:
Message-ID: <000201cc3a5d$81e54e80$85afeb80$@molloy@arm.com>
Hi Xin,
What were the original numbers before adaptive compilation?
Cheers,
James
From: llvm-commits-bounces at cs.uiuc.edu
[mailto:llvm-commits-bounces at cs.uiuc.edu] On Behalf Of Xin Tong Utoronto
Sent: 04 July 2011 16:14
To: llvm-commits at cs.uiuc.edu
Subject: [llvm-commits] [llvm jit adaptive-compilation] : Adaptive
compilation framework x86 Patch
Hi All
This patch is intended to provide support for LLVM JIT adaptive compilation
on x86 platforms. The implementation of the adaptive compilation framework
is one of the Google Summer of Code 2011 projects (
http://www.google-melange.com/gsoc/project/google/gsoc2011/timexerox/8001).
The patch is created against the LLVM branch below. It is currently reviewed
by Eric Christoper at Apple and will be applied to the LLVM branch (
https://echristo@
llvm.org/svn/llvm-project/llvm/branches/GSoC/adaptive-compilation). But more
eyes are definitely welcome. Originally, the LLVM adaptive compilation
framework was intended to be applied to LLVM head stream, but due to
concerns regarding the upcoming major changes on ExecutionEngine and MCJIT.
it is now worked in a branch and hopefully applied to the head stream once
the MCJIT changes have been completed.
This patch involves changes to
include/llvm/Target/TargetJITInfo.h
lib/Target/X86/X86JITInfo.h
lib/Target/X86/X86JITInfo.cpp
lib/Target/ARM/ARMJITInfo.h
lib/Target/ARM/ARMJITInfo.cpp
lib/Target/PowerPC/PPCJITInfo.h
lib/Target/PowerPC/PPCJITInfo.cpp
lib/ExecutionEngine/JIT/JITEmitter.cpp
lib/ExecutionEngine/JIT/JIT.h
lib/ExecutionEngine/JIT/JIT.cpp
This was tested on x86 and x86-64 under Ubuntu with
llvm test-suite
There were no regressions for the O0 - O3 JIT compilation. Additionally,
adaptive compilation currently gives better performance numbers than O1 - O3
as shown.
lli -O0
Total Time is 1068.37
lli -O1
Total Time is 1395.68
lli -O2
Total Time is 1394.81
lli -O3
Total Time is 1395.76
lli -adaptive-comp
Total Time is 1119.23
Thank You
Xin Tong
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/llvm-commits/attachments/20110704/4216c99a/attachment.html
From echristo at apple.com Mon Jul 4 13:16:32 2011
From: echristo at apple.com (Eric Christopher)
Date: Mon, 04 Jul 2011 11:16:32 -0700
Subject: [llvm-commits] [llvm jit adaptive-compilation] : Adaptive
compilation framework x86 Patch
In-Reply-To:
References:
<4e11d99c.8521e70a.2556.2dfeSMTPIN_ADDED@mx.google.com>
Message-ID: <35C48A86-CFB9-42C3-8FAA-051E3B6C1030@apple.com>
On Jul 4, 2011, at 8:58 AM, Xin Tong Utoronto wrote:
> The original numbers are the same as what are given here. As the lli -O0 - O3 is virtually the same as before if adaptive compilation is not enabled.
"The same" isn't a number?
So, that's giving total time to run the testsuite on x86 in seconds I gather. How about individual tests? Any significant regressions? Progressions? What were the top 10 of each?
-eric
From x.tong at utoronto.ca Mon Jul 4 13:44:19 2011
From: x.tong at utoronto.ca (Xin Tong Utoronto)
Date: Mon, 4 Jul 2011 14:44:19 -0400
Subject: [llvm-commits] [llvm jit adaptive-compilation] : Adaptive
compilation framework x86 Patch
In-Reply-To: <35C48A86-CFB9-42C3-8FAA-051E3B6C1030@apple.com>
References:
<4e11d99c.8521e70a.2556.2dfeSMTPIN_ADDED@mx.google.com>
<35C48A86-CFB9-42C3-8FAA-051E3B6C1030@apple.com>
Message-ID:
Thanks
Xin
On Mon, Jul 4, 2011 at 2:16 PM, Eric Christopher wrote:
>
> On Jul 4, 2011, at 8:58 AM, Xin Tong Utoronto wrote:
>
> > The original numbers are the same as what are given here. As the lli -O0
> - O3 is virtually the same as before if adaptive compilation is not enabled.
>
> "The same" isn't a number?
>
> So, that's giving total time to run the testsuite on x86 in seconds I
> gather. How about individual tests? Any significant regressions?
> Progressions? What were the top 10 of each?
>
Honestly I do not have the original numbers, I will launch a run now and
post later today or tomorrow. Right, the total time is in seconds. I will
report on progressions and regressions as well in the next post.
-Xin
>
> -eric
>
--
Kind Regards
Xin Tong
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/llvm-commits/attachments/20110704/4c1e5ad6/attachment.html
From benny.kra at googlemail.com Mon Jul 4 15:16:36 2011
From: benny.kra at googlemail.com (Benjamin Kramer)
Date: Mon, 04 Jul 2011 20:16:36 -0000
Subject: [llvm-commits] [llvm] r134379 - in /llvm/trunk:
lib/Transforms/InstCombine/InstCombineCompares.cpp
test/Transforms/InstCombine/icmp.ll
Message-ID: <20110704201636.86E0D2A6C12C@llvm.org>
Author: d0k
Date: Mon Jul 4 15:16:36 2011
New Revision: 134379
URL: http://llvm.org/viewvc/llvm-project?rev=134379&view=rev
Log:
PR10267: Don't combine an equality compare with an AND into an inequality compare when the AND has more than one use.
This can pessimize code, inequalities are generally more expensive.
Modified:
llvm/trunk/lib/Transforms/InstCombine/InstCombineCompares.cpp
llvm/trunk/test/Transforms/InstCombine/icmp.ll
Modified: llvm/trunk/lib/Transforms/InstCombine/InstCombineCompares.cpp
URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/lib/Transforms/InstCombine/InstCombineCompares.cpp?rev=134379&r1=134378&r2=134379&view=diff
==============================================================================
--- llvm/trunk/lib/Transforms/InstCombine/InstCombineCompares.cpp (original)
+++ llvm/trunk/lib/Transforms/InstCombine/InstCombineCompares.cpp Mon Jul 4 15:16:36 2011
@@ -1454,7 +1454,11 @@
return new ICmpInst(isICMP_NE ? ICmpInst::ICMP_EQ :
ICmpInst::ICMP_NE, LHSI,
Constant::getNullValue(RHS->getType()));
-
+
+ // Don't perform the following transforms if the AND has multiple uses
+ if (!BO->hasOneUse())
+ break;
+
// Replace (and X, (1 << size(X)-1) != 0) with x s< 0
if (BOC->getValue().isSignBit()) {
Value *X = BO->getOperand(0);
Modified: llvm/trunk/test/Transforms/InstCombine/icmp.ll
URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/test/Transforms/InstCombine/icmp.ll?rev=134379&r1=134378&r2=134379&view=diff
==============================================================================
--- llvm/trunk/test/Transforms/InstCombine/icmp.ll (original)
+++ llvm/trunk/test/Transforms/InstCombine/icmp.ll Mon Jul 4 15:16:36 2011
@@ -547,3 +547,15 @@
%cmp = icmp eq i32 %sub, 123
ret i1 %cmp
}
+
+; PR10267 Don't make icmps more expensive when no other inst is subsumed.
+declare void @foo(i32)
+; CHECK: @test57
+; CHECK: %and = and i32 %a, -2
+; CHECK: %cmp = icmp ne i32 %and, 0
+define i1 @test57(i32 %a) {
+ %and = and i32 %a, -2
+ %cmp = icmp ne i32 %and, 0
+ call void @foo(i32 %and)
+ ret i1 %cmp
+}
From clattner at apple.com Mon Jul 4 16:48:52 2011
From: clattner at apple.com (Chris Lattner)
Date: Mon, 04 Jul 2011 14:48:52 -0700
Subject: [llvm-commits] [PATCH] SuccIterator on bbs without terminator
insts
In-Reply-To: <4E114EF9.8080105@fim.uni-passau.de>
References: <4E10F310.4060705@fim.uni-passau.de> <4E1106A7.10101@mxc.ca>
<4E114EF9.8080105@fim.uni-passau.de>
Message-ID: <9F6878CC-83C4-462C-9C11-C730F3C74144@apple.com>
On Jul 3, 2011, at 10:26 PM, Tobias Grosser wrote:
>> Intuitively no, because all basic blocks are required to have
>> terminators. But I suspect you ran into this for a reason, and tools
>> like succ_begin/end() may not be able to assume that the CFG is valid at
>> any point in time because the IR is being modified. Could you explain
>> more about what you were doing which triggered this?
>
> It's pretty easy.
>
> In Polly we modify the CFG by adding some additional basic blocks
> (actually a branch that contains an optimized code path). Once in a
> while (because of a bug in Polly or somewhere in LLVM) I have a failing
> test case. My first step to investigate a bug is to put a breakpoint at
> the place in the code where I suspect the bug (or an assert triggered).
> My next step is to call F->viewCFG() to see the current state of the
> CFG. Unfortunately this almost never works, as the CFG is at this point
> not yet fully constructed and consequently the above assert triggers.
>
> In general I believe for debugging it would be very helpful if
> F->viewCFG() would already work during the construction of the CFG.
I agree with Nick that this is really counterintuitive, but your logic makes sense to me. Please commit with a comment explaining that getTerminator() is allowed to return null for malformed CFGs.
-Chris
From grosser at fim.uni-passau.de Mon Jul 4 18:09:02 2011
From: grosser at fim.uni-passau.de (Tobias Grosser)
Date: Mon, 04 Jul 2011 23:09:02 -0000
Subject: [llvm-commits] [llvm] r134398 -
/llvm/trunk/include/llvm/Support/CFG.h
Message-ID: <20110704230902.CBFA12A6C12C@llvm.org>
Author: grosser
Date: Mon Jul 4 18:09:02 2011
New Revision: 134398
URL: http://llvm.org/viewvc/llvm-project?rev=134398&view=rev
Log:
SuccIterator on bbs without terminator insts
Remove the assert that triggers if SuccIterator is constructed for a basic block
without a terminator instruction. Instead of triggering an assert a succ_end()
iterator is returned. This models a basic block with zero successors and allows
us to use F->viewCFG() on incompletely constructed functions.
Modified:
llvm/trunk/include/llvm/Support/CFG.h
Modified: llvm/trunk/include/llvm/Support/CFG.h
URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/include/llvm/Support/CFG.h?rev=134398&r1=134397&r2=134398&view=diff
==============================================================================
--- llvm/trunk/include/llvm/Support/CFG.h (original)
+++ llvm/trunk/include/llvm/Support/CFG.h Mon Jul 4 18:09:02 2011
@@ -109,11 +109,18 @@
// TODO: This can be random access iterator, only operator[] missing.
explicit inline SuccIterator(Term_ T) : Term(T), idx(0) {// begin iterator
- assert(T && "getTerminator returned null!");
}
inline SuccIterator(Term_ T, bool) // end iterator
- : Term(T), idx(Term->getNumSuccessors()) {
- assert(T && "getTerminator returned null!");
+ : Term(T) {
+ if (Term)
+ idx = Term->getNumSuccessors();
+ else
+ // Term == NULL happens, if a basic block is not fully constructed and
+ // consequently getTerminator() returns NULL. In this case we construct a
+ // SuccIterator which describes a basic block that has zero successors.
+ // Defining SuccIterator for incomplete and malformed CFGs is especially
+ // useful for debugging.
+ idx = 0;
}
inline const Self &operator=(const Self &I) {
@@ -201,6 +208,7 @@
/// Get the source BB of this iterator.
inline BB_ *getSource() {
+ assert(Term && "Source not available, if basic block was malformed");
return Term->getParent();
}
};
From grosser at fim.uni-passau.de Mon Jul 4 18:15:55 2011
From: grosser at fim.uni-passau.de (Tobias Grosser)
Date: Mon, 04 Jul 2011 18:15:55 -0500
Subject: [llvm-commits] [PATCH] SuccIterator on bbs without terminator
insts
In-Reply-To: <9F6878CC-83C4-462C-9C11-C730F3C74144@apple.com>
References: <4E10F310.4060705@fim.uni-passau.de>
<4E1106A7.10101@mxc.ca> <4E114EF9.8080105@fim.uni-passau.de>
<9F6878CC-83C4-462C-9C11-C730F3C74144@apple.com>
Message-ID: <4E1249AB.7070707@fim.uni-passau.de>
On 07/04/2011 04:48 PM, Chris Lattner wrote:
> On Jul 3, 2011, at 10:26 PM, Tobias Grosser wrote:
>>> Intuitively no, because all basic blocks are required to have
>>> terminators. But I suspect you ran into this for a reason, and tools
>>> like succ_begin/end() may not be able to assume that the CFG is valid at
>>> any point in time because the IR is being modified. Could you explain
>>> more about what you were doing which triggered this?
>>
>> It's pretty easy.
>>
>> In Polly we modify the CFG by adding some additional basic blocks
>> (actually a branch that contains an optimized code path). Once in a
>> while (because of a bug in Polly or somewhere in LLVM) I have a failing
>> test case. My first step to investigate a bug is to put a breakpoint at
>> the place in the code where I suspect the bug (or an assert triggered).
>> My next step is to call F->viewCFG() to see the current state of the
>> CFG. Unfortunately this almost never works, as the CFG is at this point
>> not yet fully constructed and consequently the above assert triggers.
>>
>> In general I believe for debugging it would be very helpful if
>> F->viewCFG() would already work during the construction of the CFG.
>
> I agree with Nick that this is really counterintuitive, but your logic makes sense to me. Please commit with a comment explaining that getTerminator() is allowed to return null for malformed CFGs.
Committed in 134398.
Cheers
Tobi
From grosser at fim.uni-passau.de Mon Jul 4 18:18:17 2011
From: grosser at fim.uni-passau.de (Tobias Grosser)
Date: Mon, 04 Jul 2011 23:18:17 -0000
Subject: [llvm-commits] [polly] r134400 -
/polly/trunk/test/CodeGen/single_loop_param.ll
Message-ID: <20110704231817.E48092A6C12C@llvm.org>
Author: grosser
Date: Mon Jul 4 18:18:17 2011
New Revision: 134400
URL: http://llvm.org/viewvc/llvm-project?rev=134400&view=rev
Log:
test: Remove redundant function definition
The latest version of LLVM fails, if a function is defined twice in an LLVM
bitcode file.
Modified:
polly/trunk/test/CodeGen/single_loop_param.ll
Modified: polly/trunk/test/CodeGen/single_loop_param.ll
URL: http://llvm.org/viewvc/llvm-project/polly/trunk/test/CodeGen/single_loop_param.ll?rev=134400&r1=134399&r2=134400&view=diff
==============================================================================
--- polly/trunk/test/CodeGen/single_loop_param.ll (original)
+++ polly/trunk/test/CodeGen/single_loop_param.ll Mon Jul 4 18:18:17 2011
@@ -70,9 +70,6 @@
declare void @llvm.memset.p0i8.i64(i8* nocapture, i8, i64, i32, i1) nounwind
-
-declare void @llvm.memset.p0i8.i64(i8* nocapture, i8, i64, i32, i1) nounwind
-
; CHECK: if (M >= 1) {
; CHECK: for (c2=0;c2<=M-1;c2++) {
; CHECK: Stmt_bb2(c2);
From rpaulo at apple.com Mon Jul 4 19:26:06 2011
From: rpaulo at apple.com (Rui Paulo)
Date: Mon, 04 Jul 2011 17:26:06 -0700
Subject: [llvm-commits] Patch: add contains to ImmutableList
Message-ID: <360E1DF3-0EA5-45A2-AD20-63CE242E1D48@apple.com>
Hi,
Attached is a patch to add a contains method to ImmutableList. I need this in the clang Static Analyzer.
Regards,
--
Rui Paulo
-------------- next part --------------
A non-text attachment was scrubbed...
Name: contains.diff
Type: application/octet-stream
Size: 751 bytes
Desc: not available
Url : http://lists.cs.uiuc.edu/pipermail/llvm-commits/attachments/20110704/f26a070e/attachment.obj
From nicholas at mxc.ca Mon Jul 4 21:53:22 2011
From: nicholas at mxc.ca (Nick Lewycky)
Date: Mon, 04 Jul 2011 19:53:22 -0700
Subject: [llvm-commits] Patch: add contains to ImmutableList
In-Reply-To: <360E1DF3-0EA5-45A2-AD20-63CE242E1D48@apple.com>
References: <360E1DF3-0EA5-45A2-AD20-63CE242E1D48@apple.com>
Message-ID: <4E127CA2.9050705@mxc.ca>
Rui Paulo wrote:
> Hi,
>
> Attached is a patch to add a contains method to ImmutableList. I need this in the clang Static Analyzer.
Do you really need "this->" here?:
+ for (iterator I = this->begin(), E = this->end(); I != E; ++I) {
Yes the type is templated, but it doesn't have a template base.
Secondly:
+ if (*I == V)
The existing code in ImmutableList does not care at all about how
T::operator== works, instead assuming that the objects in the list are
uniqued by address. If that assumption is okay with you, you may want to
write "if (I == &V)" instead.
Finally, are you sure that doing an O(n) scan is OK for your use case?
I'll take your word for it if it's really the right thing to do, but
just having this may encourage poor algorithm choices by others.
As an alternative, how about a function which takes a T* and returns the
ImmutableList::iterator pointing to the right element or the end()
iterator if it's not a member?
Do you have commit access?
Nick
From nicholas at mxc.ca Mon Jul 4 22:02:09 2011
From: nicholas at mxc.ca (Nick Lewycky)
Date: Mon, 04 Jul 2011 20:02:09 -0700
Subject: [llvm-commits] Patch: add contains to ImmutableList
In-Reply-To: <4E127CA2.9050705@mxc.ca>
References: <360E1DF3-0EA5-45A2-AD20-63CE242E1D48@apple.com>
<4E127CA2.9050705@mxc.ca>
Message-ID: <4E127EB1.7010101@mxc.ca>
Nick Lewycky wrote:
> Rui Paulo wrote:
>> Hi,
>>
>> Attached is a patch to add a contains method to ImmutableList. I need this in the clang Static Analyzer.
>
> Do you really need "this->" here?:
>
> + for (iterator I = this->begin(), E = this->end(); I != E; ++I) {
>
> Yes the type is templated, but it doesn't have a template base.
>
> Secondly:
>
> + if (*I == V)
>
> The existing code in ImmutableList does not care at all about how
> T::operator== works, instead assuming that the objects in the list are
> uniqued by address. If that assumption is okay with you, you may want to
> write "if (I ==&V)" instead.
On further reflection, that wouldn't work properly when T=int, for
example, as the ImmutableList would have an intrusive linked list node
for the '5' element whose doesn't match the '5' you just passed in (from
the stack).
Nick
> Finally, are you sure that doing an O(n) scan is OK for your use case?
> I'll take your word for it if it's really the right thing to do, but
> just having this may encourage poor algorithm choices by others.
>
> As an alternative, how about a function which takes a T* and returns the
> ImmutableList::iterator pointing to the right element or the end()
> iterator if it's not a member?
>
> Do you have commit access?
>
> Nick
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
>
From rdivacky at freebsd.org Tue Jul 5 07:22:51 2011
From: rdivacky at freebsd.org (Roman Divacky)
Date: Tue, 5 Jul 2011 14:22:51 +0200
Subject: [llvm-commits] [PATCH]: don't use MO_DARWIN_STUB on non-darwin
Message-ID: <20110705122251.GA23536@freebsd.org>
Hi,
In the PPC backend there's this flag MO_DARWIN_STUB that should
be set on Darwin < 10.5. The condition to set it is wrong imho.
The attached patch fixes it. With the patch I am able to build
dynamic libraries that links on FreeBSD (because the flag should
not be set there).
In the patch I basically change
if ((!MacOSX || (MacOSXVersion < 10.5)
to
if ((MacOSX && (MacOSXVersion < 10.5)
OK to commit? Or is there some hidden magic behind this that I dont see?
roman
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ppc-darwin.patch
Type: text/x-diff
Size: 1164 bytes
Desc: not available
Url : http://lists.cs.uiuc.edu/pipermail/llvm-commits/attachments/20110705/969659e8/attachment.bin
From bigcheesegs at gmail.com Tue Jul 5 09:48:59 2011
From: bigcheesegs at gmail.com (Michael J. Spencer)
Date: Tue, 05 Jul 2011 14:48:59 -0000
Subject: [llvm-commits] [llvm] r134408 -
/llvm/trunk/lib/Object/COFFObjectFile.cpp
Message-ID: <20110705144859.608652A6C12C@llvm.org>
Author: mspencer
Date: Tue Jul 5 09:48:59 2011
New Revision: 134408
URL: http://llvm.org/viewvc/llvm-project?rev=134408&view=rev
Log:
Fix warnings.
Modified:
llvm/trunk/lib/Object/COFFObjectFile.cpp
Modified: llvm/trunk/lib/Object/COFFObjectFile.cpp
URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/lib/Object/COFFObjectFile.cpp?rev=134408&r1=134407&r2=134408&view=diff
==============================================================================
--- llvm/trunk/lib/Object/COFFObjectFile.cpp (original)
+++ llvm/trunk/lib/Object/COFFObjectFile.cpp Tue Jul 5 09:48:59 2011
@@ -117,7 +117,7 @@
error_code COFFObjectFile::getSymbolAddress(DataRefImpl Symb,
uint64_t &Result) const {
const coff_symbol *symb = toSymb(Symb);
- const coff_section *Section;
+ const coff_section *Section = NULL;
if (error_code ec = getSection(symb->SectionNumber, Section))
return ec;
char Type;
@@ -138,7 +138,7 @@
// in the same section as this symbol, and looking for either the next
// symbol, or the end of the section.
const coff_symbol *symb = toSymb(Symb);
- const coff_section *Section;
+ const coff_section *Section = NULL;
if (error_code ec = getSection(symb->SectionNumber, Section))
return ec;
char Type;
@@ -171,7 +171,7 @@
uint32_t Characteristics = 0;
if (symb->SectionNumber > 0) {
- const coff_section *Section;
+ const coff_section *Section = NULL;
if (error_code ec = getSection(symb->SectionNumber, Section))
return ec;
Characteristics = Section->Characteristics;
From bigcheesegs at gmail.com Tue Jul 5 09:49:08 2011
From: bigcheesegs at gmail.com (Michael J. Spencer)
Date: Tue, 05 Jul 2011 14:49:08 -0000
Subject: [llvm-commits] [llvm] r134409 -
/llvm/trunk/include/llvm/Object/ObjectFile.h
Message-ID: <20110705144908.97E4D2A6C12C@llvm.org>
Author: mspencer
Date: Tue Jul 5 09:49:08 2011
New Revision: 134409
URL: http://llvm.org/viewvc/llvm-project?rev=134409&view=rev
Log:
Fix 80-col.
Modified:
llvm/trunk/include/llvm/Object/ObjectFile.h
Modified: llvm/trunk/include/llvm/Object/ObjectFile.h
URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/include/llvm/Object/ObjectFile.h?rev=134409&r1=134408&r2=134409&view=diff
==============================================================================
--- llvm/trunk/include/llvm/Object/ObjectFile.h (original)
+++ llvm/trunk/include/llvm/Object/ObjectFile.h Tue Jul 5 09:49:08 2011
@@ -44,7 +44,10 @@
const ObjectFile *OwningObject;
public:
- RelocationRef() : OwningObject(NULL) { std::memset(&RelocationPimpl, 0, sizeof(RelocationPimpl)); }
+ RelocationRef() : OwningObject(NULL) {
+ std::memset(&RelocationPimpl, 0, sizeof(RelocationPimpl));
+ }
+
RelocationRef(DataRefImpl RelocationP, const ObjectFile *Owner);
bool operator==(const RelocationRef &Other) const;
@@ -59,7 +62,10 @@
const ObjectFile *OwningObject;
public:
- SymbolRef() : OwningObject(NULL) { std::memset(&SymbolPimpl, 0, sizeof(SymbolPimpl)); }
+ SymbolRef() : OwningObject(NULL) {
+ std::memset(&SymbolPimpl, 0, sizeof(SymbolPimpl));
+ }
+
SymbolRef(DataRefImpl SymbolP, const ObjectFile *Owner);
bool operator==(const SymbolRef &Other) const;
@@ -86,7 +92,10 @@
const ObjectFile *OwningObject;
public:
- SectionRef() : OwningObject(NULL) { std::memset(&SectionPimpl, 0, sizeof(SectionPimpl)); }
+ SectionRef() : OwningObject(NULL) {
+ std::memset(&SectionPimpl, 0, sizeof(SectionPimpl));
+ }
+
SectionRef(DataRefImpl SectionP, const ObjectFile *Owner);
bool operator==(const SectionRef &Other) const;
From grosser at fim.uni-passau.de Tue Jul 5 10:23:26 2011
From: grosser at fim.uni-passau.de (Tobias Grosser)
Date: Tue, 5 Jul 2011 10:23:26 -0500
Subject: [llvm-commits] [PATCH 0/6] Cleanup DisplayGraph and make
F->viewCFG() non-blocking
Message-ID:
Hi,
while debugging I figured out that the F->viewCFG() function blocks until the
graph viewer is closed. This is anoying, as I often would like to keep the graph
open while I continue my debugging session.
To solve this problem I looked into the DisplayGraph function and figured out
that displaying a graph without waiting for the viewer to return was already
available, but hidden between lines of redundant code and many preprocessor
macros. The feature was also only available for a single graph viewer
(ghostview).
This patchset restructures the DisplayGraph function such that it is more
readable and that common code is actually shared between the different viewers.
It also adds support for non-blocking graph viewing for all viewers.
The last patch enables this non-blocking behaviour for the F->viewCFG()
function, but keeps the blocking behaviour of 'opt -view-cfg'.
Besides the size of the patches, almost all do not intend any functional
changes. If, because of missing test cases, a small bug slipped in, it should be
easy to understand and fix. Just bug me, if DisplayGraph starts to act weird.
OK to commit?
Tobi
Tobias Grosser (6):
Use a separate function to get graph viewer path
Use a separate function to translate from dot to ps
DisplayGraph: Delete dot file earlier
Use a separate function to select the graph viewer
DisplayGraph: Unify code of the different viewers
F->viewCFG() does not wait any more.
include/llvm/Support/GraphWriter.h | 14 ++-
lib/Analysis/CFGPrinter.cpp | 14 ++-
lib/Support/GraphWriter.cpp | 207 ++++++++++++++++++++++--------------
3 files changed, 147 insertions(+), 88 deletions(-)
From grosser at fim.uni-passau.de Tue Jul 5 10:23:27 2011
From: grosser at fim.uni-passau.de (Tobias Grosser)
Date: Tue, 5 Jul 2011 10:23:27 -0500
Subject: [llvm-commits] [PATCH 1/6] Use a separate function to get graph
viewer path
In-Reply-To:
References:
Message-ID: <9d9a58fec4ac3a272dd94e4adfb1c2a523cc23dd.1309878809.git.tobias@grosser.es>
This reduces the size of the DisplayGraph function, moves many preprocessor
macros out of the main function and is a step to our long term goal of detecting
the graph viewer at run time.
No functional change intended.
---
include/llvm/Support/GraphWriter.h | 8 ++++
lib/Support/GraphWriter.cpp | 68 ++++++++++++++++++++++++++---------
2 files changed, 58 insertions(+), 18 deletions(-)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Use-a-separate-function-to-get-graph-viewer-path.patch
Type: text/x-patch
Size: 5067 bytes
Desc: not available
Url : http://lists.cs.uiuc.edu/pipermail/llvm-commits/attachments/20110705/fbc73aeb/attachment.bin
From grosser at fim.uni-passau.de Tue Jul 5 10:23:28 2011
From: grosser at fim.uni-passau.de (Tobias Grosser)
Date: Tue, 5 Jul 2011 10:23:28 -0500
Subject: [llvm-commits] [PATCH 2/6] Use a separate function to translate
from dot to ps
In-Reply-To: <9d9a58fec4ac3a272dd94e4adfb1c2a523cc23dd.1309878809.git.tobias@grosser.es>
References:
<9d9a58fec4ac3a272dd94e4adfb1c2a523cc23dd.1309878809.git.tobias@grosser.es>
Message-ID:
This reduces the size of the DisplayGraph function quite a bit.
No functional change intended.
---
lib/Support/GraphWriter.cpp | 130 +++++++++++++++++++++++--------------------
1 files changed, 70 insertions(+), 60 deletions(-)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0002-Use-a-separate-function-to-translate-from-dot-to-ps.patch
Type: text/x-patch
Size: 4196 bytes
Desc: not available
Url : http://lists.cs.uiuc.edu/pipermail/llvm-commits/attachments/20110705/61ed3491/attachment.bin
From grosser at fim.uni-passau.de Tue Jul 5 10:23:30 2011
From: grosser at fim.uni-passau.de (Tobias Grosser)
Date: Tue, 5 Jul 2011 10:23:30 -0500
Subject: [llvm-commits] [PATCH 4/6] Use a separate function to select the
graph viewer
In-Reply-To:
References:
<9d9a58fec4ac3a272dd94e4adfb1c2a523cc23dd.1309878809.git.tobias@grosser.es>
Message-ID:
This moves all the compile time decisions in a single function. Later this
function can be enhanced such that we can select the graph viewer at run time.
No functional change intended.
---
include/llvm/Support/GraphWriter.h | 3 +-
lib/Support/GraphWriter.cpp | 167 ++++++++++++++++++++---------------
2 files changed, 97 insertions(+), 73 deletions(-)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0004-Use-a-separate-function-to-select-the-graph-viewer.patch
Type: text/x-patch
Size: 7106 bytes
Desc: not available
Url : http://lists.cs.uiuc.edu/pipermail/llvm-commits/attachments/20110705/f49d6028/attachment.bin
From grosser at fim.uni-passau.de Tue Jul 5 10:23:29 2011
From: grosser at fim.uni-passau.de (Tobias Grosser)
Date: Tue, 5 Jul 2011 10:23:29 -0500
Subject: [llvm-commits] [PATCH 3/6] DisplayGraph: Delete dot file earlier
In-Reply-To:
References:
<9d9a58fec4ac3a272dd94e4adfb1c2a523cc23dd.1309878809.git.tobias@grosser.es>
Message-ID:
We delete the dot file as early as possible to unify the control flow.
---
lib/Support/GraphWriter.cpp | 7 +++----
1 files changed, 3 insertions(+), 4 deletions(-)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0003-DisplayGraph-Delete-dot-file-earlier.patch
Type: text/x-patch
Size: 1385 bytes
Desc: not available
Url : http://lists.cs.uiuc.edu/pipermail/llvm-commits/attachments/20110705/79bf93f1/attachment.bin
From grosser at fim.uni-passau.de Tue Jul 5 10:23:32 2011
From: grosser at fim.uni-passau.de (Tobias Grosser)
Date: Tue, 5 Jul 2011 10:23:32 -0500
Subject: [llvm-commits] [PATCH 6/6] F->viewCFG() does not wait any more.
In-Reply-To: <8e8a89a999f46e0a7a8de48c4fc7dcde4940ab7e.1309878809.git.tobias@grosser.es>
References:
<9d9a58fec4ac3a272dd94e4adfb1c2a523cc23dd.1309878809.git.tobias@grosser.es>
<8e8a89a999f46e0a7a8de48c4fc7dcde4940ab7e.1309878809.git.tobias@grosser.es>
Message-ID: <6286526c717311b23fd599dd8ee8985d00fb26ad.1309878809.git.tobias@grosser.es>
F->viewCFG() is mainly used from the debugger. There it is often useful to
keep the graph available, while continuing debugging. Hence, we do not want to
wait until the graph viewer is closed, but return immediately. This patch does
not change the blocking behaviour of 'opt -view-cfg'.
---
include/llvm/Support/GraphWriter.h | 5 +++--
lib/Analysis/CFGPrinter.cpp | 14 ++++++++++----
2 files changed, 13 insertions(+), 6 deletions(-)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0006-F-viewCFG-does-not-wait-any-more.patch
Type: text/x-patch
Size: 2294 bytes
Desc: not available
Url : http://lists.cs.uiuc.edu/pipermail/llvm-commits/attachments/20110705/4954e3e5/attachment-0001.bin
From grosser at fim.uni-passau.de Tue Jul 5 10:23:31 2011
From: grosser at fim.uni-passau.de (Tobias Grosser)
Date: Tue, 5 Jul 2011 10:23:31 -0500
Subject: [llvm-commits] [PATCH 5/6] DisplayGraph: Unify code of the
different viewers
In-Reply-To:
References:
<9d9a58fec4ac3a272dd94e4adfb1c2a523cc23dd.1309878809.git.tobias@grosser.es>
Message-ID: <8e8a89a999f46e0a7a8de48c4fc7dcde4940ab7e.1309878809.git.tobias@grosser.es>
Restructure the code, such that code that needs to be executed for all
viewers is shared. This patch also adds the 'wait' feature to all viewers. This
feature was previously only implemented for ghostview.
---
lib/Support/GraphWriter.cpp | 101 +++++++++++++++++--------------------------
1 files changed, 40 insertions(+), 61 deletions(-)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0005-DisplayGraph-Unify-code-of-the-different-viewers.patch
Type: text/x-patch
Size: 4299 bytes
Desc: not available
Url : http://lists.cs.uiuc.edu/pipermail/llvm-commits/attachments/20110705/b9d0ec35/attachment-0001.bin
From stoklund at 2pi.dk Tue Jul 5 10:38:37 2011
From: stoklund at 2pi.dk (Jakob Stoklund Olesen)
Date: Tue, 05 Jul 2011 15:38:37 -0000
Subject: [llvm-commits] [llvm] r134412 -
/llvm/trunk/lib/CodeGen/RegAllocGreedy.cpp
Message-ID: <20110705153837.B5E3B2A6C12C@llvm.org>
Author: stoklund
Date: Tue Jul 5 10:38:37 2011
New Revision: 134412
URL: http://llvm.org/viewvc/llvm-project?rev=134412&view=rev
Log:
Tweak comment and debug output.
Modified:
llvm/trunk/lib/CodeGen/RegAllocGreedy.cpp
Modified: llvm/trunk/lib/CodeGen/RegAllocGreedy.cpp
URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/lib/CodeGen/RegAllocGreedy.cpp?rev=134412&r1=134411&r2=134412&view=diff
==============================================================================
--- llvm/trunk/lib/CodeGen/RegAllocGreedy.cpp (original)
+++ llvm/trunk/lib/CodeGen/RegAllocGreedy.cpp Tue Jul 5 10:38:37 2011
@@ -958,7 +958,8 @@
//
// ~ Interference after last use.
// |---o---o--o| Live-out on stack, late last use.
- // =========____ Copy to stack after LSP, overlap MainIntv.
+ // ============ Copy to stack after LSP, overlap MainIntv.
+ // \_____ Stack interval is live-out.
//
if (!RegOut && Intf.first() > BI.LastUse.getBoundaryIndex()) {
assert(RegIn && "Stack-in, stack-out should already be handled");
@@ -998,8 +999,8 @@
// The interference is overlapping somewhere we wanted to use MainIntv. That
// means we need to create a local interval that can be allocated a
// different register.
- DEBUG(dbgs() << ", creating local interval.\n");
unsigned LocalIntv = SE->openIntv();
+ DEBUG(dbgs() << ", creating local interval " << LocalIntv << ".\n");
// We may be creating copies directly between MainIntv and LocalIntv,
// bypassing the stack interval. When we do that, we should never use the
From stoklund at 2pi.dk Tue Jul 5 10:38:41 2011
From: stoklund at 2pi.dk (Jakob Stoklund Olesen)
Date: Tue, 05 Jul 2011 15:38:41 -0000
Subject: [llvm-commits] [llvm] r134413 - in /llvm/trunk:
lib/CodeGen/InlineSpiller.cpp lib/CodeGen/LiveRangeEdit.cpp
test/CodeGen/X86/crash.ll
Message-ID: <20110705153841.399C52A6C12E@llvm.org>
Author: stoklund
Date: Tue Jul 5 10:38:41 2011
New Revision: 134413
URL: http://llvm.org/viewvc/llvm-project?rev=134413&view=rev
Log:
Fix PR10277.
Remat during spilling triggers dead code elimination. If a phi-def
becomes unused, that may also cause live ranges to split into separate
connected components.
This type of splitting is different from normal live range splitting. In
particular, there may not be a common original interval.
When the split range is its own original, make sure that the new
siblings are also their own originals. The range being split cannot be
used as an original since it doesn't cover the new siblings.
Modified:
llvm/trunk/lib/CodeGen/InlineSpiller.cpp
llvm/trunk/lib/CodeGen/LiveRangeEdit.cpp
llvm/trunk/test/CodeGen/X86/crash.ll
Modified: llvm/trunk/lib/CodeGen/InlineSpiller.cpp
URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/lib/CodeGen/InlineSpiller.cpp?rev=134413&r1=134412&r2=134413&view=diff
==============================================================================
--- llvm/trunk/lib/CodeGen/InlineSpiller.cpp (original)
+++ llvm/trunk/lib/CodeGen/InlineSpiller.cpp Tue Jul 5 10:38:41 2011
@@ -425,6 +425,7 @@
// Check possible sibling copies.
if (VNI->isPHIDef() || VNI->getCopy()) {
VNInfo *OrigVNI = OrigLI.getVNInfoAt(VNI->def);
+ assert(OrigVNI && "Def outside original live range");
if (OrigVNI->def != VNI->def)
DefMI = traceSiblingValue(Reg, VNI, OrigVNI);
}
Modified: llvm/trunk/lib/CodeGen/LiveRangeEdit.cpp
URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/lib/CodeGen/LiveRangeEdit.cpp?rev=134413&r1=134412&r2=134413&view=diff
==============================================================================
--- llvm/trunk/lib/CodeGen/LiveRangeEdit.cpp (original)
+++ llvm/trunk/lib/CodeGen/LiveRangeEdit.cpp Tue Jul 5 10:38:41 2011
@@ -298,10 +298,16 @@
if (NumComp <= 1)
continue;
++NumFracRanges;
+ bool IsOriginal = VRM.getOriginal(LI->reg) == LI->reg;
DEBUG(dbgs() << NumComp << " components: " << *LI << '\n');
SmallVector Dups(1, LI);
for (unsigned i = 1; i != NumComp; ++i) {
Dups.push_back(&createFrom(LI->reg, LIS, VRM));
+ // If LI is an original interval that hasn't been split yet, make the new
+ // intervals their own originals instead of referring to LI. The original
+ // interval must contain all the split products, and LI doesn't.
+ if (IsOriginal)
+ VRM.setIsSplitFromReg(Dups.back()->reg, 0);
if (delegate_)
delegate_->LRE_DidCloneVirtReg(Dups.back()->reg, LI->reg);
}
Modified: llvm/trunk/test/CodeGen/X86/crash.ll
URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/test/CodeGen/X86/crash.ll?rev=134413&r1=134412&r2=134413&view=diff
==============================================================================
--- llvm/trunk/test/CodeGen/X86/crash.ll (original)
+++ llvm/trunk/test/CodeGen/X86/crash.ll Tue Jul 5 10:38:41 2011
@@ -215,3 +215,104 @@
}
declare i64 @llvm.objectsize.i64(i8*, i1) nounwind readnone
+
+; PR10277
+; This test has dead code elimination caused by remat during spilling.
+; DCE causes a live interval to break into connected components.
+; One of the components is spilled.
+
+%t2 = type { i8 }
+%t9 = type { %t10 }
+%t10 = type { %t11 }
+%t11 = type { %t12 }
+%t12 = type { %t13*, %t13*, %t13* }
+%t13 = type { %t14*, %t15, %t15 }
+%t14 = type opaque
+%t15 = type { i8, i32, i32 }
+%t16 = type { %t17, i8* }
+%t17 = type { %t18 }
+%t18 = type { %t19 }
+%t19 = type { %t20*, %t20*, %t20* }
+%t20 = type { i32, i32 }
+%t21 = type { %t13* }
+
+define void @_ZNK4llvm17MipsFrameLowering12emitPrologueERNS_15MachineFunctionE() ssp align 2 {
+bb:
+ %tmp = load %t9** undef, align 4, !tbaa !0
+ %tmp2 = getelementptr inbounds %t9* %tmp, i32 0, i32 0
+ %tmp3 = getelementptr inbounds %t9* %tmp, i32 0, i32 0, i32 0, i32 0, i32 1
+ br label %bb4
+
+bb4: ; preds = %bb37, %bb
+ %tmp5 = phi i96 [ undef, %bb ], [ %tmp38, %bb37 ]
+ %tmp6 = phi i96 [ undef, %bb ], [ %tmp39, %bb37 ]
+ br i1 undef, label %bb34, label %bb7
+
+bb7: ; preds = %bb4
+ %tmp8 = load i32* undef, align 4
+ %tmp9 = and i96 %tmp6, 4294967040
+ %tmp10 = zext i32 %tmp8 to i96
+ %tmp11 = shl nuw nsw i96 %tmp10, 32
+ %tmp12 = or i96 %tmp9, %tmp11
+ %tmp13 = or i96 %tmp12, 1
+ %tmp14 = load i32* undef, align 4
+ %tmp15 = and i96 %tmp5, 4294967040
+ %tmp16 = zext i32 %tmp14 to i96
+ %tmp17 = shl nuw nsw i96 %tmp16, 32
+ %tmp18 = or i96 %tmp15, %tmp17
+ %tmp19 = or i96 %tmp18, 1
+ %tmp20 = load i8* undef, align 1
+ %tmp21 = and i8 %tmp20, 1
+ %tmp22 = icmp ne i8 %tmp21, 0
+ %tmp23 = select i1 %tmp22, i96 %tmp19, i96 %tmp13
+ %tmp24 = select i1 %tmp22, i96 %tmp13, i96 %tmp19
+ store i96 %tmp24, i96* undef, align 4
+ %tmp25 = load %t13** %tmp3, align 4
+ %tmp26 = icmp eq %t13* %tmp25, undef
+ br i1 %tmp26, label %bb28, label %bb27
+
+bb27: ; preds = %bb7
+ br label %bb29
+
+bb28: ; preds = %bb7
+ call void @_ZNSt6vectorIN4llvm11MachineMoveESaIS1_EE13_M_insert_auxEN9__gnu_cxx17__normal_iteratorIPS1_S3_EERKS1_(%t10* %tmp2, %t21* byval align 4 undef, %t13* undef)
+ br label %bb29
+
+bb29: ; preds = %bb28, %bb27
+ store i96 %tmp23, i96* undef, align 4
+ %tmp30 = load %t13** %tmp3, align 4
+ br i1 false, label %bb33, label %bb31
+
+bb31: ; preds = %bb29
+ %tmp32 = getelementptr inbounds %t13* %tmp30, i32 1
+ store %t13* %tmp32, %t13** %tmp3, align 4
+ br label %bb37
+
+bb33: ; preds = %bb29
+ unreachable
+
+bb34: ; preds = %bb4
+ br i1 undef, label %bb36, label %bb35
+
+bb35: ; preds = %bb34
+ store %t13* null, %t13** %tmp3, align 4
+ br label %bb37
+
+bb36: ; preds = %bb34
+ call void @_ZNSt6vectorIN4llvm11MachineMoveESaIS1_EE13_M_insert_auxEN9__gnu_cxx17__normal_iteratorIPS1_S3_EERKS1_(%t10* %tmp2, %t21* byval align 4 undef, %t13* undef)
+ br label %bb37
+
+bb37: ; preds = %bb36, %bb35, %bb31
+ %tmp38 = phi i96 [ %tmp23, %bb31 ], [ %tmp5, %bb35 ], [ %tmp5, %bb36 ]
+ %tmp39 = phi i96 [ %tmp24, %bb31 ], [ %tmp6, %bb35 ], [ %tmp6, %bb36 ]
+ %tmp40 = add i32 undef, 1
+ br label %bb4
+}
+
+declare %t14* @_ZN4llvm9MCContext16CreateTempSymbolEv(%t2*)
+
+declare void @_ZNSt6vectorIN4llvm11MachineMoveESaIS1_EE13_M_insert_auxEN9__gnu_cxx17__normal_iteratorIPS1_S3_EERKS1_(%t10*, %t21* byval align 4, %t13*)
+
+declare void @llvm.lifetime.start(i64, i8* nocapture) nounwind
+
+declare void @llvm.lifetime.end(i64, i8* nocapture) nounwind
From grosbach at apple.com Tue Jul 5 11:05:50 2011
From: grosbach at apple.com (Jim Grosbach)
Date: Tue, 05 Jul 2011 16:05:50 -0000
Subject: [llvm-commits] [llvm] r134415 -
/llvm/trunk/lib/Target/ARM/ARMFrameLowering.cpp
Message-ID: <20110705160550.AC7722A6C12C@llvm.org>
Author: grosbach
Date: Tue Jul 5 11:05:50 2011
New Revision: 134415
URL: http://llvm.org/viewvc/llvm-project?rev=134415&view=rev
Log:
ARM estimateStackSize() needs to account for simplified call frames.
If the function allocates reserved stack space for callee argument frames,
estimateStackSize() needs to account for that, as it doesn't show up as
ordinary frame objects. Otherwise, a callee with a large argument list will
throw off the calculations for whether to allocate an emergency spill slot
and we get assert() failures in the register scavenger.
rdar://9715469
Modified:
llvm/trunk/lib/Target/ARM/ARMFrameLowering.cpp
Modified: llvm/trunk/lib/Target/ARM/ARMFrameLowering.cpp
URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/lib/Target/ARM/ARMFrameLowering.cpp?rev=134415&r1=134414&r2=134415&view=diff
==============================================================================
--- llvm/trunk/lib/Target/ARM/ARMFrameLowering.cpp (original)
+++ llvm/trunk/lib/Target/ARM/ARMFrameLowering.cpp Tue Jul 5 11:05:50 2011
@@ -739,20 +739,52 @@
/// estimateStackSize - Estimate and return the size of the frame.
/// FIXME: Make generic?
static unsigned estimateStackSize(MachineFunction &MF) {
- const MachineFrameInfo *FFI = MF.getFrameInfo();
+ const MachineFrameInfo *MFI = MF.getFrameInfo();
+ const TargetFrameLowering *TFI = MF.getTarget().getFrameLowering();
+ const TargetRegisterInfo *RegInfo = MF.getTarget().getRegisterInfo();
+ unsigned MaxAlign = MFI->getMaxAlignment();
int Offset = 0;
- for (int i = FFI->getObjectIndexBegin(); i != 0; ++i) {
- int FixedOff = -FFI->getObjectOffset(i);
+
+ // This code is very, very similar to PEI::calculateFrameObjectOffsets().
+ // It really should be refactored to share code. Until then, changes
+ // should keep in mind that there's tight coupling between the two.
+
+ for (int i = MFI->getObjectIndexBegin(); i != 0; ++i) {
+ int FixedOff = -MFI->getObjectOffset(i);
if (FixedOff > Offset) Offset = FixedOff;
}
- for (unsigned i = 0, e = FFI->getObjectIndexEnd(); i != e; ++i) {
- if (FFI->isDeadObjectIndex(i))
+ for (unsigned i = 0, e = MFI->getObjectIndexEnd(); i != e; ++i) {
+ if (MFI->isDeadObjectIndex(i))
continue;
- Offset += FFI->getObjectSize(i);
- unsigned Align = FFI->getObjectAlignment(i);
+ Offset += MFI->getObjectSize(i);
+ unsigned Align = MFI->getObjectAlignment(i);
// Adjust to alignment boundary
Offset = (Offset+Align-1)/Align*Align;
+
+ MaxAlign = std::max(Align, MaxAlign);
}
+
+ if (MFI->adjustsStack() && TFI->hasReservedCallFrame(MF))
+ Offset += MFI->getMaxCallFrameSize();
+
+ // Round up the size to a multiple of the alignment. If the function has
+ // any calls or alloca's, align to the target's StackAlignment value to
+ // ensure that the callee's frame or the alloca data is suitably aligned;
+ // otherwise, for leaf functions, align to the TransientStackAlignment
+ // value.
+ unsigned StackAlign;
+ if (MFI->adjustsStack() || MFI->hasVarSizedObjects() ||
+ (RegInfo->needsStackRealignment(MF) && MFI->getObjectIndexEnd() != 0))
+ StackAlign = TFI->getStackAlignment();
+ else
+ StackAlign = TFI->getTransientStackAlignment();
+
+ // If the frame pointer is eliminated, all frame offsets will be relative to
+ // SP not FP. Align to MaxAlign so this works.
+ StackAlign = std::max(StackAlign, MaxAlign);
+ unsigned AlignMask = StackAlign - 1;
+ Offset = (Offset + AlignMask) & ~uint64_t(AlignMask);
+
return (unsigned)Offset;
}
From bob.wilson at apple.com Tue Jul 5 11:15:47 2011
From: bob.wilson at apple.com (Bob Wilson)
Date: Tue, 05 Jul 2011 09:15:47 -0700
Subject: [llvm-commits] Built-in "expect" support
In-Reply-To: <8FEF2DE3-2F1B-417E-A79F-DB6CF76B5949@apple.com>
References: <8FEF2DE3-2F1B-417E-A79F-DB6CF76B5949@apple.com>
Message-ID: <794AD71F-6FFF-4A2A-A0FF-B0CBE00A6235@apple.com>
On Jul 2, 2011, at 6:00 PM, Jakub Staszak wrote:
> Hello,
>
> This patch introduces built-in support. It uses llvm.expect intrinsics to create "branch_weights" metadata if run with -md-expect or with -O.
>
> Comments are welcome.
I think the new "expect" intrinsic should be overloaded for all integer types, instead of being forced to i64 only. Although it should work OK without the overloading, I can imagine cases where the extra sign/zero-extends and truncates for i64 could change the way the code is optimized. Overloading it just seems like a better fit for how this intrinsic is used.
Unless I missed something, this is your first patch using the "block_weights" metadata, and you haven't yet described the intended usage or format of that metadata. You'll need to provide those details and some documentation. For now, let's proceed with the understanding that everything about "block_weights" metadata is tentative and subject to change.
The "expect" intrinsic should have the IntrNoMem property, not IntrReadArgMem.
I think your new pass should run after early CSE. One of the reasons we decided to implement builtin_expect this way is to allow some simple propagation of builtin_expect calls that are not directly inside conditionals. You haven't implemented that yet, but early CSE should help when the time comes.
The long methods in your MetadataExpect pass should be defined outside the class.
The arbitrary constants "4" and "64" for likely and unlikely branch weights should not be used directly. These should be symbolic constants defined in the MetadataExpect class. Once we have more code using this, we may want to adjust those values.
The "MetadataExpect" and "md-expect" names are not very descriptive of what the transform pass does, which is to convert expect intrinsics to block_weights metadata. I'll see if I can think of better alternatives -- let me know if you have ideas.
Please add a comment for your change to IntrinsicLowering.cpp
From rafael.espindola at gmail.com Tue Jul 5 11:45:37 2011
From: rafael.espindola at gmail.com (=?ISO-8859-1?Q?Rafael_=C1vila_de_Esp=EDndola?=)
Date: Tue, 05 Jul 2011 12:45:37 -0400
Subject: [llvm-commits] [llvm] r134413 - in /llvm/trunk:
lib/CodeGen/InlineSpiller.cpp lib/CodeGen/LiveRangeEdit.cpp
test/CodeGen/X86/crash.ll
In-Reply-To: <20110705153841.399C52A6C12E@llvm.org>
References: <20110705153841.399C52A6C12E@llvm.org>
Message-ID: <4E133FB1.9010506@gmail.com>
On 07/05/2011 11:38 AM, Jakob Stoklund Olesen wrote:
> Author: stoklund
> Date: Tue Jul 5 10:38:41 2011
> New Revision: 134413
>
> URL: http://llvm.org/viewvc/llvm-project?rev=134413&view=rev
> Log:
> Fix PR10277.
>
> Remat during spilling triggers dead code elimination. If a phi-def
> becomes unused, that may also cause live ranges to split into separate
> connected components.
>
> This type of splitting is different from normal live range splitting. In
> particular, there may not be a common original interval.
>
> When the split range is its own original, make sure that the new
> siblings are also their own originals. The range being split cannot be
> used as an original since it doesn't cover the new siblings.
>
Thanks!
I had just managed to produce a testcase without tail duplication :-)
Do you have a reference on what was going on? Why do we track the
original live interval when splitting?
Cheers,
Rafael
From joerg at britannica.bec.de Tue Jul 5 11:51:10 2011
From: joerg at britannica.bec.de (Joerg Sonnenberger)
Date: Tue, 5 Jul 2011 18:51:10 +0200
Subject: [llvm-commits] [PATCH 2/6] Use a separate function to translate
from dot to ps
In-Reply-To:
References:
Message-ID: <20110705165109.GA14428@britannica.bec.de>
On Tue, Jul 05, 2011 at 10:23:28AM -0500, Tobias Grosser wrote:
> + sys::Path prog;
> +
> + // Set default grapher
> +#if HAVE_CIRCO
> + prog = sys::Path(LLVM_PATH_CIRCO);
> +#endif
> +#if HAVE_TWOPI
> + prog = sys::Path(LLVM_PATH_TWOPI);
> +#endif
> +#if HAVE_NEATO
> + prog = sys::Path(LLVM_PATH_NEATO);
> +#endif
> +#if HAVE_FDP
> + prog = sys::Path(LLVM_PATH_FDP);
> +#endif
> +#if HAVE_DOT
> + prog = sys::Path(LLVM_PATH_DOT);
> +#endif
> +
> + // Find which program the user wants
> +#if HAVE_DOT
> + if (program == GraphProgram::DOT)
> + prog = sys::Path(LLVM_PATH_DOT);
> +#endif
> +#if (HAVE_FDP)
> + if (program == GraphProgram::FDP)
> + prog = sys::Path(LLVM_PATH_FDP);
> +#endif
> +#if (HAVE_NEATO)
> + if (program == GraphProgram::NEATO)
> + prog = sys::Path(LLVM_PATH_NEATO);
> +#endif
> +#if (HAVE_TWOPI)
> + if (program == GraphProgram::TWOPI)
> + prog = sys::Path(LLVM_PATH_TWOPI);
> +#endif
> +#if (HAVE_CIRCO)
> + if (program == GraphProgram::CIRCO)
> + prog = sys::Path(LLVM_PATH_CIRCO);
> +#endif
This is assigning prog at least twice. This should be a switch on
program and default to dot/fdp/neato/twopi/circo without full path if it
couldn't be found during installation. I would even argue that no full
path should be hard-coded without a good reason, but that's a separate
change.
Joerg
From atrick at apple.com Tue Jul 5 13:19:39 2011
From: atrick at apple.com (Andrew Trick)
Date: Tue, 05 Jul 2011 18:19:39 -0000
Subject: [llvm-commits] [llvm] r134423 -
/llvm/trunk/lib/Transforms/Scalar/IndVarSimplify.cpp
Message-ID: <20110705181939.DAD2A2A6C12C@llvm.org>
Author: atrick
Date: Tue Jul 5 13:19:39 2011
New Revision: 134423
URL: http://llvm.org/viewvc/llvm-project?rev=134423&view=rev
Log:
indvars -disable-iv-rewrite: avoid multiple IVs in weird cases.
Putting back the helper that I removed on 7/1 to do this right.
Modified:
llvm/trunk/lib/Transforms/Scalar/IndVarSimplify.cpp
Modified: llvm/trunk/lib/Transforms/Scalar/IndVarSimplify.cpp
URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/lib/Transforms/Scalar/IndVarSimplify.cpp?rev=134423&r1=134422&r2=134423&view=diff
==============================================================================
--- llvm/trunk/lib/Transforms/Scalar/IndVarSimplify.cpp (original)
+++ llvm/trunk/lib/Transforms/Scalar/IndVarSimplify.cpp Tue Jul 5 13:19:39 2011
@@ -608,6 +608,8 @@
Instruction *NarrowDef,
Instruction *WideDef);
+ const SCEVAddRecExpr *GetWideRecurrence(Instruction *NarrowUse);
+
Instruction *WidenIVUse(Use &NarrowDefUse, Instruction *NarrowDef,
Instruction *WideDef);
@@ -704,6 +706,33 @@
return true;
}
+// GetWideRecurrence - Is this instruction potentially interesting from IVUsers'
+// perspective after widening it's type? In other words, can the extend be
+// safely hoisted out of the loop with SCEV reducing the value to a recurrence
+// on the same loop. If so, return the sign or zero extended
+// recurrence. Otherwise return NULL.
+const SCEVAddRecExpr *WidenIV::GetWideRecurrence(Instruction *NarrowUse) {
+ if (!SE->isSCEVable(NarrowUse->getType()))
+ return 0;
+
+ const SCEV *NarrowExpr = SE->getSCEV(NarrowUse);
+ if (SE->getTypeSizeInBits(NarrowExpr->getType())
+ >= SE->getTypeSizeInBits(WideType)) {
+ // NarrowUse implicitly widens its operand. e.g. a gep with a narrow
+ // index. So don't follow this use.
+ return 0;
+ }
+
+ const SCEV *WideExpr = IsSigned ?
+ SE->getSignExtendExpr(NarrowExpr, WideType) :
+ SE->getZeroExtendExpr(NarrowExpr, WideType);
+ const SCEVAddRecExpr *AddRec = dyn_cast(WideExpr);
+ if (!AddRec || AddRec->getLoop() != L)
+ return 0;
+
+ return AddRec;
+}
+
/// WidenIVUse - Determine whether an individual user of the narrow IV can be
/// widened. If so, return the wide clone of the user.
Instruction *WidenIV::WidenIVUse(Use &NarrowDefUse, Instruction *NarrowDef,
@@ -753,24 +782,7 @@
}
// Does this user itself evaluate to a recurrence after widening?
- const SCEVAddRecExpr *WideAddRec = 0;
- if (SE->isSCEVable(NarrowUse->getType())) {
- const SCEV *NarrowExpr = SE->getSCEV(NarrowUse);
- if (SE->getTypeSizeInBits(NarrowExpr->getType())
- >= SE->getTypeSizeInBits(WideType)) {
- // NarrowUse implicitly widens its operand. e.g. a gep with a narrow
- // index. We have already extended the operand, so we're done.
- return 0;
- }
- const SCEV *WideExpr = IsSigned ?
- SE->getSignExtendExpr(NarrowExpr, WideType) :
- SE->getZeroExtendExpr(NarrowExpr, WideType);
-
- // Only widen past values that evaluate to a recurrence in the same loop.
- const SCEVAddRecExpr *AddRec = dyn_cast(WideExpr);
- if (AddRec && AddRec->getLoop() == L)
- WideAddRec = AddRec;
- }
+ const SCEVAddRecExpr *WideAddRec = GetWideRecurrence(NarrowUse);
if (!WideAddRec) {
// This user does not evaluate to a recurence after widening, so don't
// follow it. Instead insert a Trunc to kill off the original use,
From eli.friedman at gmail.com Tue Jul 5 13:21:20 2011
From: eli.friedman at gmail.com (Eli Friedman)
Date: Tue, 05 Jul 2011 18:21:20 -0000
Subject: [llvm-commits] [llvm] r134424 - in /llvm/trunk:
lib/Target/X86/AsmParser/X86AsmParser.cpp lib/Target/X86/X86InstrFormats.td
lib/Target/X86/X86InstrSSE.td test/MC/X86/x86-64.s
Message-ID: <20110705182120.9A67D2A6C12C@llvm.org>
Author: efriedma
Date: Tue Jul 5 13:21:20 2011
New Revision: 134424
URL: http://llvm.org/viewvc/llvm-project?rev=134424&view=rev
Log:
Add assembler/disassembler support for non-AVX pclmulqdq. While I'm here, use proper aliases for the pclmullqlqdq and friends. PR10269.
Modified:
llvm/trunk/lib/Target/X86/AsmParser/X86AsmParser.cpp
llvm/trunk/lib/Target/X86/X86InstrFormats.td
llvm/trunk/lib/Target/X86/X86InstrSSE.td
llvm/trunk/test/MC/X86/x86-64.s
Modified: llvm/trunk/lib/Target/X86/AsmParser/X86AsmParser.cpp
URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/lib/Target/X86/AsmParser/X86AsmParser.cpp?rev=134424&r1=134423&r2=134424&view=diff
==============================================================================
--- llvm/trunk/lib/Target/X86/AsmParser/X86AsmParser.cpp (original)
+++ llvm/trunk/lib/Target/X86/AsmParser/X86AsmParser.cpp Tue Jul 5 13:21:20 2011
@@ -710,23 +710,6 @@
}
}
- // FIXME: Hack to recognize vpclmuldq
- if (PatchedName.startswith("vpclmul")) {
- unsigned CLMULQuadWordSelect = StringSwitch(
- PatchedName.slice(7, PatchedName.size() - 2))
- .Case("lqlq", 0x00) // src1[63:0], src2[63:0]
- .Case("hqlq", 0x01) // src1[127:64], src2[63:0]
- .Case("lqhq", 0x10) // src1[63:0], src2[127:64]
- .Case("hqhq", 0x11) // src1[127:64], src2[127:64]
- .Default(~0U);
- if (CLMULQuadWordSelect != ~0U) {
- ExtraImmOp = MCConstantExpr::Create(CLMULQuadWordSelect,
- getParser().getContext());
- assert(PatchedName.endswith("dq") && "Unexpected mnemonic!");
- PatchedName = "vpclmulqdq";
- }
- }
-
Operands.push_back(X86Operand::CreateToken(PatchedName, NameLoc));
if (ExtraImmOp)
Modified: llvm/trunk/lib/Target/X86/X86InstrFormats.td
URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/lib/Target/X86/X86InstrFormats.td?rev=134424&r1=134423&r2=134424&view=diff
==============================================================================
--- llvm/trunk/lib/Target/X86/X86InstrFormats.td (original)
+++ llvm/trunk/lib/Target/X86/X86InstrFormats.td Tue Jul 5 13:21:20 2011
@@ -460,6 +460,11 @@
class CLMULIi8 o, Format F, dag outs, dag ins, string asm,
listpattern>
: Ii8, TA,
+ OpSize, Requires<[HasCLMUL]>;
+
+class AVXCLMULIi8 o, Format F, dag outs, dag ins, string asm,
+ listpattern>
+ : Ii8, TA,
OpSize, VEX_4V, Requires<[HasAVX, HasCLMUL]>;
// FMA3 Instruction Templates
Modified: llvm/trunk/lib/Target/X86/X86InstrSSE.td
URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/lib/Target/X86/X86InstrSSE.td?rev=134424&r1=134423&r2=134424&view=diff
==============================================================================
--- llvm/trunk/lib/Target/X86/X86InstrSSE.td (original)
+++ llvm/trunk/lib/Target/X86/X86InstrSSE.td Tue Jul 5 13:21:20 2011
@@ -5195,33 +5195,52 @@
// CLMUL Instructions
//===----------------------------------------------------------------------===//
-// Only the AVX version of CLMUL instructions are described here.
-
// Carry-less Multiplication instructions
-def VPCLMULQDQrr : CLMULIi8<0x44, MRMSrcReg, (outs VR128:$dst),
+let Constraints = "$src1 = $dst" in {
+def PCLMULQDQrr : CLMULIi8<0x44, MRMSrcReg, (outs VR128:$dst),
+ (ins VR128:$src1, VR128:$src2, i8imm:$src3),
+ "pclmulqdq\t{$src3, $src2, $dst|$dst, $src2, $src3}",
+ []>;
+
+def PCLMULQDQrm : CLMULIi8<0x44, MRMSrcMem, (outs VR128:$dst),
+ (ins VR128:$src1, i128mem:$src2, i8imm:$src3),
+ "pclmulqdq\t{$src3, $src2, $dst|$dst, $src2, $src3}",
+ []>;
+}
+
+// AVX carry-less Multiplication instructions
+def VPCLMULQDQrr : AVXCLMULIi8<0x44, MRMSrcReg, (outs VR128:$dst),
(ins VR128:$src1, VR128:$src2, i8imm:$src3),
"vpclmulqdq\t{$src3, $src2, $src1, $dst|$dst, $src1, $src2, $src3}",
[]>;
-def VPCLMULQDQrm : CLMULIi8<0x44, MRMSrcMem, (outs VR128:$dst),
+def VPCLMULQDQrm : AVXCLMULIi8<0x44, MRMSrcMem, (outs VR128:$dst),
(ins VR128:$src1, i128mem:$src2, i8imm:$src3),
"vpclmulqdq\t{$src3, $src2, $src1, $dst|$dst, $src1, $src2, $src3}",
[]>;
-// Assembler Only
-multiclass avx_vpclmul {
- def rr : I<0, Pseudo, (outs VR128:$dst), (ins VR128:$src1, VR128:$src2),
- !strconcat(asm, "\t{$src2, $src1, $dst|$dst, $src1, $src2}"),
- []>;
-
- def rm : I<0, Pseudo, (outs VR128:$dst), (ins VR128:$src1, i128mem:$src2),
- !strconcat(asm, "\t{$src2, $src1, $dst|$dst, $src1, $src2}"),
- []>;
+
+multiclass pclmul_alias {
+ def : InstAlias;
+
+ def : InstAlias;
+
+ def : InstAlias;
+
+ def : InstAlias;
}
-defm VPCLMULHQHQDQ : avx_vpclmul<"vpclmulhqhqdq">;
-defm VPCLMULHQLQDQ : avx_vpclmul<"vpclmulhqlqdq">;
-defm VPCLMULLQHQDQ : avx_vpclmul<"vpclmullqhqdq">;
-defm VPCLMULLQLQDQ : avx_vpclmul<"vpclmullqlqdq">;
+defm : pclmul_alias<"hqhq", 0x11>;
+defm : pclmul_alias<"hqlq", 0x01>;
+defm : pclmul_alias<"lqhq", 0x10>;
+defm : pclmul_alias<"lqlq", 0x00>;
//===----------------------------------------------------------------------===//
// AVX Instructions
Modified: llvm/trunk/test/MC/X86/x86-64.s
URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/test/MC/X86/x86-64.s?rev=134424&r1=134423&r2=134424&view=diff
==============================================================================
--- llvm/trunk/test/MC/X86/x86-64.s (original)
+++ llvm/trunk/test/MC/X86/x86-64.s Tue Jul 5 13:21:20 2011
@@ -1148,3 +1148,19 @@
// CHECK: movntiq
movntiq %rax, (%rdi)
movnti %rax, (%rdi)
+
+// CHECK: pclmulqdq $17, %xmm0, %xmm1
+// CHECK: encoding: [0x66,0x0f,0x3a,0x44,0xc8,0x11]
+pclmulhqhqdq %xmm0, %xmm1
+
+// CHECK: pclmulqdq $1, %xmm0, %xmm1
+// CHECK: encoding: [0x66,0x0f,0x3a,0x44,0xc8,0x01]
+pclmulqdq $1, %xmm0, %xmm1
+
+// CHECK: pclmulqdq $16, (%rdi), %xmm1
+// CHECK: encoding: [0x66,0x0f,0x3a,0x44,0x0f,0x10]
+pclmullqhqdq (%rdi), %xmm1
+
+// CHECK: pclmulqdq $0, (%rdi), %xmm1
+// CHECK: encoding: [0x66,0x0f,0x3a,0x44,0x0f,0x00]
+pclmulqdq $0, (%rdi), %xmm1
From tobias at grosser.es Tue Jul 5 13:32:42 2011
From: tobias at grosser.es (Tobias Grosser)
Date: Tue, 05 Jul 2011 13:32:42 -0500
Subject: [llvm-commits] [PATCH 2/6] Use a separate function to translate
from dot to ps
In-Reply-To: <20110705165109.GA14428@britannica.bec.de>
References:
<20110705165109.GA14428@britannica.bec.de>
Message-ID: <4E1358CA.6030102@grosser.es>
On 07/05/2011 11:51 AM, Joerg Sonnenberger wrote:
> On Tue, Jul 05, 2011 at 10:23:28AM -0500, Tobias Grosser wrote:
>> + sys::Path prog;
>> +
>> + // Set default grapher
>> +#if HAVE_CIRCO
>> + prog = sys::Path(LLVM_PATH_CIRCO);
>> +#endif
>> +#if HAVE_TWOPI
>> + prog = sys::Path(LLVM_PATH_TWOPI);
>> +#endif
>> +#if HAVE_NEATO
>> + prog = sys::Path(LLVM_PATH_NEATO);
>> +#endif
>> +#if HAVE_FDP
>> + prog = sys::Path(LLVM_PATH_FDP);
>> +#endif
>> +#if HAVE_DOT
>> + prog = sys::Path(LLVM_PATH_DOT);
>> +#endif
>> +
>> + // Find which program the user wants
>> +#if HAVE_DOT
>> + if (program == GraphProgram::DOT)
>> + prog = sys::Path(LLVM_PATH_DOT);
>> +#endif
>> +#if (HAVE_FDP)
>> + if (program == GraphProgram::FDP)
>> + prog = sys::Path(LLVM_PATH_FDP);
>> +#endif
>> +#if (HAVE_NEATO)
>> + if (program == GraphProgram::NEATO)
>> + prog = sys::Path(LLVM_PATH_NEATO);
>> +#endif
>> +#if (HAVE_TWOPI)
>> + if (program == GraphProgram::TWOPI)
>> + prog = sys::Path(LLVM_PATH_TWOPI);
>> +#endif
>> +#if (HAVE_CIRCO)
>> + if (program == GraphProgram::CIRCO)
>> + prog = sys::Path(LLVM_PATH_CIRCO);
>> +#endif
>
> This is assigning prog at least twice. This should be a switch on
> program and default to dot/fdp/neato/twopi/circo without full path if it
> couldn't be found during installation. I would even argue that no full
> path should be hard-coded without a good reason, but that's a separate
> change.
Hi Joerg,
first of all, this is the existing code and the only thing I did was to
move it into a separate function such that this code is split into
smaller more understandable pieces. For this patch I would prefer to not
touch the existing code to make it very clear that the comment "No
functional change intended" actually holds.
In general I fully agree with you that hardcoding paths is not a good
idea. Making this change should be a lot easier, after the DisplayGraph
function became a little bit more readable.
In respect of replacing this chain of conditions with a switch, As
stated before, I would prefer to not do this in this commit. I attached
a patch that could be committed in a subsequent commit. This patch also
does not change the behaviour, but changes only the style. The resulting
code will be:
switch (program) {
#if HAVE_DOT
case GraphProgram::DOT: prog = sys::Path(LLVM_PATH_DOT); break;
#endif
#if HAVE_FDP
case GraphProgram::FDP: prog = sys::Path(LLVM_PATH_FDP); break;
#endif
#if HAVE_NEATO
case GraphProgram::NEATO: prog = sys::Path(LLVM_PATH_NEATO); break;
#endif
#if HAVE_TWOPI
case GraphProgram::TWOPI: prog = sys::Path(LLVM_PATH_TWOPI); break;
#endif
#if HAVE_CIRCO
case GraphProgram::CIRCO: prog = sys::Path(LLVM_PATH_CIRCO); break;
#endif
default:
#if HAVE_DOT
prog = sys::Path(LLVM_PATH_DOT);
#elif HAVE_FDP
prog = sys::Path(LLVM_PATH_FDP);
#elif HAVE_NEATO
prog = sys::Path(LLVM_PATH_NEATO);
#elif HAVE_TWOPI
prog = sys::Path(LLVM_PATH_TWOPI);
#elif HAVE_CIRCO
prog = sys::Path(LLVM_PATH_CIRCO);
#else
llvm_unreachable("No graph program available");
#endif
}
Reducing/removing the use of absolute paths is not yet done. I agree
this is something we want, however I have not yet thought enough about
this to provide a robust patch.
Tobi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0007-GraphWriter-Use-switch-for-chain-of-conditions.patch
Type: text/x-diff
Size: 2773 bytes
Desc: not available
Url : http://lists.cs.uiuc.edu/pipermail/llvm-commits/attachments/20110705/85b45479/attachment.bin
From rafael.espindola at gmail.com Tue Jul 5 13:41:47 2011
From: rafael.espindola at gmail.com (Rafael Espindola)
Date: Tue, 05 Jul 2011 18:41:47 -0000
Subject: [llvm-commits] [llvm] r134427 -
/llvm/trunk/lib/Object/COFFObjectFile.cpp
Message-ID: <20110705184147.E8F872A6C12C@llvm.org>
Author: rafael
Date: Tue Jul 5 13:41:47 2011
New Revision: 134427
URL: http://llvm.org/viewvc/llvm-project?rev=134427&view=rev
Log:
Compare all 4 bytes of the header.
Modified:
llvm/trunk/lib/Object/COFFObjectFile.cpp
Modified: llvm/trunk/lib/Object/COFFObjectFile.cpp
URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/lib/Object/COFFObjectFile.cpp?rev=134427&r1=134426&r2=134427&view=diff
==============================================================================
--- llvm/trunk/lib/Object/COFFObjectFile.cpp (original)
+++ llvm/trunk/lib/Object/COFFObjectFile.cpp Tue Jul 5 13:41:47 2011
@@ -309,8 +309,9 @@
if (!checkSize(Data, ec, 0x3c + 8)) return;
HeaderStart += *reinterpret_cast(base() + 0x3c);
// Check the PE header. ("PE\0\0")
- if (StringRef(reinterpret_cast(base() + HeaderStart), 4)
- != "PE\0\0") {
+ StringRef Actual(reinterpret_cast(base() + HeaderStart), 4);
+ StringRef Expcted("PE\0\0", 4);
+ if (Actual != Expcted) {
ec = object_error::parse_failed;
return;
}
From stoklund at 2pi.dk Tue Jul 5 13:46:42 2011
From: stoklund at 2pi.dk (Jakob Stoklund Olesen)
Date: Tue, 05 Jul 2011 18:46:42 -0000
Subject: [llvm-commits] [llvm] r134428 -
/llvm/trunk/lib/CodeGen/RegAllocGreedy.cpp
Message-ID: <20110705184642.71F6B2A6C12C@llvm.org>
Author: stoklund
Date: Tue Jul 5 13:46:42 2011
New Revision: 134428
URL: http://llvm.org/viewvc/llvm-project?rev=134428&view=rev
Log:
Break infinite loop when the Hopfield network oscillates.
This is impossible in theory, I can prove it. In practice, our near-zero
threshold can cause the network to oscillate between equally good
solutions.
Modified:
llvm/trunk/lib/CodeGen/RegAllocGreedy.cpp
Modified: llvm/trunk/lib/CodeGen/RegAllocGreedy.cpp
URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/lib/CodeGen/RegAllocGreedy.cpp?rev=134428&r1=134427&r2=134428&view=diff
==============================================================================
--- llvm/trunk/lib/CodeGen/RegAllocGreedy.cpp (original)
+++ llvm/trunk/lib/CodeGen/RegAllocGreedy.cpp Tue Jul 5 13:46:42 2011
@@ -649,8 +649,6 @@
for (;;) {
ArrayRef NewBundles = SpillPlacer->getRecentPositive();
- if (NewBundles.empty())
- break;
// Find new through blocks in the periphery of PrefRegBundles.
for (int i = 0, e = NewBundles.size(); i != e; ++i) {
unsigned Bundle = NewBundles[i];
@@ -670,12 +668,12 @@
}
}
// Any new blocks to add?
- if (ActiveBlocks.size() > AddedTo) {
- ArrayRef Add(&ActiveBlocks[AddedTo],
- ActiveBlocks.size() - AddedTo);
- addThroughConstraints(Intf, Add);
- AddedTo = ActiveBlocks.size();
- }
+ if (ActiveBlocks.size() == AddedTo)
+ break;
+ addThroughConstraints(Intf,
+ ArrayRef(ActiveBlocks).slice(AddedTo));
+ AddedTo = ActiveBlocks.size();
+
// Perhaps iterating can enable more bundles?
SpillPlacer->iterate();
}
From raghesh.a at gmail.com Tue Jul 5 13:51:34 2011
From: raghesh.a at gmail.com (Raghesh Aloor)
Date: Tue, 05 Jul 2011 18:51:34 -0000
Subject: [llvm-commits] [polly] r134429 - in /polly/trunk/www:
documentation.html documentation/memaccess.html
Message-ID: <20110705185134.DD7CB2A6C12C@llvm.org>
Author: raghesh
Date: Tue Jul 5 13:51:34 2011
New Revision: 134429
URL: http://llvm.org/viewvc/llvm-project?rev=134429&view=rev
Log:
www: Updating memaccess documentation
This is a complete rewrite to memaccess.html file. This removed
some unwanted html tags.
Modified:
polly/trunk/www/documentation.html
polly/trunk/www/documentation/memaccess.html
Modified: polly/trunk/www/documentation.html
URL: http://llvm.org/viewvc/llvm-project/polly/trunk/www/documentation.html?rev=134429&r1=134428&r2=134429&view=diff
==============================================================================
--- polly/trunk/www/documentation.html (original)
+++ polly/trunk/www/documentation.html Tue Jul 5 13:51:34 2011
@@ -18,8 +18,8 @@
-Support
-for
-memory access
-transformations in Polly
-
-
This project adds
-memory access transformations to Polly. In many cases
-changing the memory access pattern yields to better data
-locality or removes
-dependences that would otherwise block
-transformations. They may also
-allow LLVM to use registers to store
-certain values.
-
-
-An examples which uses this feature is given below
-
-
+
+
+
+
Polly - Memory access optimizations
+
+
WARNING: This project is part of the Google Summer of Code 2011. Hence,
+it is currently not finished, but it is in the design and implementation stage.
+The Ideas/Plans described here may not yet be implemented in Polly and may be
+changed during the actual implementation.
+
+The project which adds memory access transformations to Polly. In many cases
+changing the memory access pattern yields to better data locality or removes
+dependences that would otherwise block transformations.
+
+
An examples which uses this feature is given below.
+
Consider the following loop
-
-
for
-(i = 0; i < 8; i++)
-sum += A[i];
-
-
-With support for memory access transformation this loop can be executed
-in parallel. It can be
-transformed to
-
-
-
<create
-and
-initialize an array 'tmp'
-with size 4>
-for (i = 0; i < 8; i++) {
-tmp[i % 4] += A[i];
-}
-sum = tmp[0] + tmp[1] + tmp[2]
-+ tmp[3];
-
-
-With the help of some optimizer (like
-PluTo) the following code can be
-generated, where the outer loop is
-parallel.
-
parfor (ii =
-0; ii < 4; ii++) {
- tmp[ii] = 0;
- for (i = ii * 2; i < (ii+1) * 2; i++)
- tmp[ii] += A[i];
-
}
-sum = tmp[0] + tmp[1] + tmp[2] +
-tmp[3];
-
-
TODO
-
-
Step 1
-
-Polly exports its polyhedral description in a JSCoP file. Define how
-memory
-layout transformations are going to be expressed in Polly and
-in
-the JSCOP file.
-A simple example is given below.
-
-Consider the following loop.
-
-
for
-(i
-= 0; i < 12; i++)
- A[i] = 0;
-
-
-In the JSCOP file the memory is represented as follows.
-
-
-"accesses":
-[{
-
-"kind":
-"write",
-
-"relation":
-"{
-Stmt[i] -> A[i]
-}"
- }]
-
-
-Suppose
-we want to perform a transformation such that the following
-code is generated
-
-
for
-(i
-= 0; i < 12; i++)
-
- A[0] = i;
-
-
-The corresponding JSCOP file represenation would be
-
-
-"accesses":
-[{
-
-"kind":
-"read",
-
-"relation":
-"{
-Stmt[i] -> A[0]
-}"
- }]
-
-
-We need to detect this access function change.
+
+for (i = 0; i < 8; i++)
+ sum += A[i];
+
+Through memory access transformations this loop can be executed in parallel.
+It can be transformed to
+
+// Create and initialize an array 'tmp' with size 4
+for (i = 0; i < 8; i++)
+ tmp[i % 4] += A[i];
+sum = tmp[0] + tmp[1] + tmp[2] + tmp[3];
+
+
+Optimizers like PluTo can schedule the code such that an outer, parallel
+loop is created:
+
+parfor (ii = 0; ii < 4; ii++) {
+ tmp[ii] = 0;
+ for (i = ii * 2; i < (ii+1) * 2; i++)
+ tmp[ii] += A[i];
+ }
+sum = tmp[0] + tmp[1] + tmp[2] + tmp[3];
+
+
+
TODO
+
Step 1
+Polly exports its polyhedral description in a JSCoP file. Define how memory
+layout transformations are expressed in Polly and in the JSCOP file.
+Example:
+
+
Consider the following loop.
+
+for (i = 0; i < 12; i++)
+ A[i] = 0;
+
+In the JSCOP file the memory accesses are represented as follows.
+
+"accesses": [{
+ "kind": "write",
+ "relation": "{ Stmt[i] -> A[i] }"
+}]
+
+To perform a transformation we generate the following code:
+
+for (i = 0; i < 12; i++)
+ A[0] = i;
+
+The representation in the JSCoP file is:
+
+"accesses": [{
+ "kind": "read",
+ "relation": "{ Stmt[i] -> A[0] }"
+}]
+
+We need to detect this access function change.
-
Modified: polly/trunk/www/documentation/memaccess.html
URL: http://llvm.org/viewvc/llvm-project/polly/trunk/www/documentation/memaccess.html?rev=134429&r1=134428&r2=134429&view=diff
==============================================================================
--- polly/trunk/www/documentation/memaccess.html (original)
+++ polly/trunk/www/documentation/memaccess.html Tue Jul 5 13:51:34 2011
@@ -1,143 +1,87 @@
-
+
+