Re: [llvm-commits] CVS: llvm/lib/CodeGen/LiveIntervalAnalysis.cpp RegAllocLinearScan.cpp VirtRegMap.cpp VirtRegMap.h
First cut trivial re-materialization support.
Woot!
unsigned reg = rep(mop.getReg());
mii-getOperand(i).setReg(reg);
+// If the definition instruction is re-materializable,
its spill
+// weight is zero.
LiveInterval RegInt = getInterval(reg);
-RegInt.weight +=
- (mop.isUse() + mop.isDef()) * pow(10.0F, (int)
loopDepth);
+if (!RegInt.remat) {
+ RegInt.weight +=
+(mop.isUse() + mop.isDef()) * pow(10.0F, (int)
loopDepth);
+}
Should it really be zero? It should definitely be lower that a
normal value, but zero seems low. The loop depth should still be
taken into consideration.
@@ -497,6 +515,9 @@
}
} else {
+// Can't safely assume definition is rematierializable anymore.
typo in comment.
@@ -53,14 +60,20 @@
/// read/written by this instruction.
MI2VirtMapTy MI2VirtMap;
+/// ReMatMap - This is irtual register to re-materialized
instruction
typo
+/// mapping. Each virtual register whose definition is going
to be
+/// re-materialized has an entry in it.
+std::mapunsigned, const MachineInstr* ReMatMap;
+/// ReMatId - Instead of assigning a stack slot to a to be
rematerialized
+/// virtaul register, an unique id is being assinged. This
keeps track of
2 x typo
+/// the highest id used so far. Note, this starts at (118)
to avoid
+/// conflicts with stack slot numbers.
+int ReMatId;
-Chris
___
llvm-commits mailing list
llvm-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
Re: [llvm-commits] CVS: llvm/lib/CodeGen/LiveIntervalAnalysis.cpp RegAllocLinearScan.cpp VirtRegMap.cpp VirtRegMap.h
On Mar 30, 2007, at 2:44 PM, Chris Lattner wrote:
First cut trivial re-materialization support.
Woot!
unsigned reg = rep(mop.getReg());
mii-getOperand(i).setReg(reg);
+// If the definition instruction is re-
materializable, its spill
+// weight is zero.
LiveInterval RegInt = getInterval(reg);
-RegInt.weight +=
- (mop.isUse() + mop.isDef()) * pow(10.0F, (int)
loopDepth);
+if (!RegInt.remat) {
+ RegInt.weight +=
+(mop.isUse() + mop.isDef()) * pow(10.0F, (int)
loopDepth);
+}
Should it really be zero? It should definitely be lower that a
normal value, but zero seems low. The loop depth should still be
taken into consideration.
Funny you should mention this. I am re-evaluating this right now. My
thinking is loads (load from constantpool or stack slots) would have
the normal weight. The rest will have half the weight.
Evan
@@ -497,6 +515,9 @@
}
} else {
+// Can't safely assume definition is rematierializable anymore.
typo in comment.
@@ -53,14 +60,20 @@
/// read/written by this instruction.
MI2VirtMapTy MI2VirtMap;
+/// ReMatMap - This is irtual register to re-materialized
instruction
typo
+/// mapping. Each virtual register whose definition is going
to be
+/// re-materialized has an entry in it.
+std::mapunsigned, const MachineInstr* ReMatMap;
+/// ReMatId - Instead of assigning a stack slot to a to be
rematerialized
+/// virtaul register, an unique id is being assinged. This
keeps track of
2 x typo
+/// the highest id used so far. Note, this starts at (118)
to avoid
+/// conflicts with stack slot numbers.
+int ReMatId;
-Chris
___
llvm-commits mailing list
llvm-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
Re: [llvm-commits] CVS: llvm/lib/CodeGen/LiveIntervalAnalysis.cpp RegAllocLinearScan.cpp VirtRegMap.cpp VirtRegMap.h
On Mar 30, 2007, at 3:03 PM, Evan Cheng wrote:
unsigned reg = rep(mop.getReg());
mii-getOperand(i).setReg(reg);
+// If the definition instruction is re-
materializable, its spill
+// weight is zero.
LiveInterval RegInt = getInterval(reg);
-RegInt.weight +=
- (mop.isUse() + mop.isDef()) * pow(10.0F, (int)
loopDepth);
+if (!RegInt.remat) {
+ RegInt.weight +=
+(mop.isUse() + mop.isDef()) * pow(10.0F, (int)
loopDepth);
+}
Should it really be zero? It should definitely be lower that a
normal value, but zero seems low. The loop depth should still be
taken into consideration.
Funny you should mention this. I am re-evaluating this right now.
My thinking is loads (load from constantpool or stack slots) would
have the normal weight. The rest will have half the weight.
Why not just make everything half weight? What would be lost?
-Chris
___
llvm-commits mailing list
llvm-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
Re: [llvm-commits] CVS: llvm/lib/CodeGen/LiveIntervalAnalysis.cpp RegAllocLinearScan.cpp VirtRegMap.cpp VirtRegMap.h
On Mar 30, 2007, at 3:09 PM, Chris Lattner wrote:
On Mar 30, 2007, at 3:03 PM, Evan Cheng wrote:
unsigned reg = rep(mop.getReg());
mii-getOperand(i).setReg(reg);
+// If the definition instruction is re-
materializable, its spill
+// weight is zero.
LiveInterval RegInt = getInterval(reg);
-RegInt.weight +=
- (mop.isUse() + mop.isDef()) * pow(10.0F, (int)
loopDepth);
+if (!RegInt.remat) {
+ RegInt.weight +=
+(mop.isUse() + mop.isDef()) * pow(10.0F, (int)
loopDepth);
+}
Should it really be zero? It should definitely be lower that a
normal value, but zero seems low. The loop depth should still be
taken into consideration.
Funny you should mention this. I am re-evaluating this right now.
My thinking is loads (load from constantpool or stack slots) would
have the normal weight. The rest will have half the weight.
Why not just make everything half weight? What would be lost?
To avoid a common problem. A value live-in to a function and is
loaded from stack slot and used in a loop. You do not want to
rematerialize this and end up issuing the load in the loop.
This is tricky to get right. I am not sure simple heuristics can
cover all the cases.
Evan
-Chris
___
llvm-commits mailing list
llvm-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
Re: [llvm-commits] CVS: llvm/lib/CodeGen/LiveIntervalAnalysis.cpp RegAllocLinearScan.cpp VirtRegMap.cpp VirtRegMap.h
- (mop.isUse() + mop.isDef()) * pow(10.0F, (int)
loopDepth);
+if (!RegInt.remat) {
+ RegInt.weight +=
+(mop.isUse() + mop.isDef()) * pow(10.0F, (int)
loopDepth);
+}
Should it really be zero? It should definitely be lower that a
normal value, but zero seems low. The loop depth should still
be taken into consideration.
Funny you should mention this. I am re-evaluating this right now.
My thinking is loads (load from constantpool or stack slots)
would have the normal weight. The rest will have half the weight.
Why not just make everything half weight? What would be lost?
To avoid a common problem. A value live-in to a function and is
loaded from stack slot and used in a loop. You do not want to
rematerialize this and end up issuing the load in the loop.
This is tricky to get right. I am not sure simple heuristics can
cover all the cases.
Okay, so just look to see if the instr has the TargetInstrInfo::LOAD
flag on it?
-Chris
___
llvm-commits mailing list
llvm-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
Re: [llvm-commits] CVS: llvm/lib/CodeGen/LiveIntervalAnalysis.cpp RegAllocLinearScan.cpp
Dear Mr. Laskey,
This change broke the LLVM build on OpenBSD. Would it be possible to
use FLT_MAX instead of HUGE_VALF? FLT_MAX from float.h looks more portable.
-- John T.
Jim Laskey wrote:
Changes in directory llvm/lib/CodeGen:
LiveIntervalAnalysis.cpp updated: 1.190 - 1.191
RegAllocLinearScan.cpp updated: 1.129 - 1.130
---
Log message:
Use correct value for float HUGH_VAL.
---
Diffs of the changes: (+6 -6)
LiveIntervalAnalysis.cpp |8
RegAllocLinearScan.cpp |4 ++--
2 files changed, 6 insertions(+), 6 deletions(-)
Index: llvm/lib/CodeGen/LiveIntervalAnalysis.cpp
diff -u llvm/lib/CodeGen/LiveIntervalAnalysis.cpp:1.190
llvm/lib/CodeGen/LiveIntervalAnalysis.cpp:1.191
--- llvm/lib/CodeGen/LiveIntervalAnalysis.cpp:1.190 Tue Nov 7 01:18:40 2006
+++ llvm/lib/CodeGen/LiveIntervalAnalysis.cpp Tue Nov 7 06:25:45 2006
@@ -219,7 +219,7 @@
// range the use follows def immediately, it doesn't make sense to
spill
// it and hope it will be easier to allocate for this li.
if (isZeroLengthInterval(LI))
-LI.weight = float(HUGE_VAL);
+LI.weight = HUGE_VALF;
if (EnableReweight) {
// Divide the weight of the interval by its size. This encourages
@@ -265,7 +265,7 @@
std::vectorLiveInterval* added;
- assert(li.weight != HUGE_VAL
+ assert(li.weight != HUGE_VALF
attempt to spill already spilled interval!);
DEBUG(std::cerr \t\t\t\tadding intervals for spills for interval: ;
@@ -340,7 +340,7 @@
// the spill weight is now infinity as it
// cannot be spilled again
-nI.weight = float(HUGE_VAL);
+nI.weight = HUGE_VALF;
if (HasUse) {
LiveRange LR(getLoadIndex(index), getUseIndex(index),
@@ -1362,6 +1362,6 @@
LiveInterval LiveIntervals::createInterval(unsigned reg) {
float Weight = MRegisterInfo::isPhysicalRegister(reg) ?
- (float)HUGE_VAL : 0.0F;
+ HUGE_VALF : 0.0F;
return LiveInterval(reg, Weight);
}
Index: llvm/lib/CodeGen/RegAllocLinearScan.cpp
diff -u llvm/lib/CodeGen/RegAllocLinearScan.cpp:1.129
llvm/lib/CodeGen/RegAllocLinearScan.cpp:1.130
--- llvm/lib/CodeGen/RegAllocLinearScan.cpp:1.129 Tue Oct 24 09:35:25 2006
+++ llvm/lib/CodeGen/RegAllocLinearScan.cpp Tue Nov 7 06:25:45 2006
@@ -545,7 +545,7 @@
DEBUG(std::cerr \tassigning stack slot at interval *cur :\n);
// Find a register to spill.
- float minWeight = float(HUGE_VAL);
+ float minWeight = HUGE_VALF;
unsigned minReg = 0;
for (TargetRegisterClass::iterator i = RC-allocation_order_begin(*mf_),
e = RC-allocation_order_end(*mf_); i != e; ++i) {
@@ -582,7 +582,7 @@
// if the current has the minimum weight, we need to spill it and
// add any added intervals back to unhandled, and restart
// linearscan.
- if (cur-weight != float(HUGE_VAL) cur-weight = minWeight) {
+ if (cur-weight != HUGE_VALF cur-weight = minWeight) {
DEBUG(std::cerr \t\t\tspilling(c): *cur '\n';);
int slot = vrm_-assignVirt2StackSlot(cur-reg);
std::vectorLiveInterval* added =
___
llvm-commits mailing list
llvm-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
___
llvm-commits mailing list
llvm-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
Re: [llvm-commits] CVS: llvm/lib/CodeGen/LiveIntervalAnalysis.cpp RegAllocLinearScan.cpp
John,Both are defined on Darwin, FLT_MAX in float.h and HUGE_VALF in math.h. However, neither header seems to be based on a BSD header. I choose HUGE_VALF because it was also defined in the LINUX and FREEBSD math.h headers (seemed like confirmation to me.) I'll wait for Chris to make the call. (might uses a #ifndef HUGE_VALF thingame.)Cheers,-- JimOn Nov 8, 2006, at 12:03 PM, John Criswell wrote:Dear Mr. Laskey,This change broke the LLVM build on OpenBSD. Would it be possible touse FLT_MAX instead of HUGE_VALF? FLT_MAX from float.h looks more portable.-- John T.Jim Laskey wrote: Changes in directory llvm/lib/CodeGen:LiveIntervalAnalysis.cpp updated: 1.190 - 1.191RegAllocLinearScan.cpp updated: 1.129 - 1.130---Log message:Use correct value for float HUGH_VAL.---Diffs of the changes: (+6 -6) LiveIntervalAnalysis.cpp | 8 RegAllocLinearScan.cpp | 4 ++-- 2 files changed, 6 insertions(+), 6 deletions(-)Index: llvm/lib/CodeGen/LiveIntervalAnalysis.cppdiff -u llvm/lib/CodeGen/LiveIntervalAnalysis.cpp:1.190 llvm/lib/CodeGen/LiveIntervalAnalysis.cpp:1.191--- llvm/lib/CodeGen/LiveIntervalAnalysis.cpp:1.190 Tue Nov 7 01:18:40 2006+++ llvm/lib/CodeGen/LiveIntervalAnalysis.cpp Tue Nov 7 06:25:45 2006@@ -219,7 +219,7 @@ // range the use follows def immediately, it doesn't make sense to spill // it and hope it will be easier to allocate for this li. if (isZeroLengthInterval(LI))- LI.weight = float(HUGE_VAL);+ LI.weight = HUGE_VALF; if (EnableReweight) { // Divide the weight of the interval by its size. This encourages @@ -265,7 +265,7 @@ std::vectorLiveInterval* added;- assert(li.weight != HUGE_VAL + assert(li.weight != HUGE_VALF "attempt to spill already spilled interval!"); DEBUG(std::cerr "\t\t\t\tadding intervals for spills for interval: ";@@ -340,7 +340,7 @@ // the spill weight is now infinity as it // cannot be spilled again- nI.weight = float(HUGE_VAL);+ nI.weight = HUGE_VALF; if (HasUse) { LiveRange LR(getLoadIndex(index), getUseIndex(index),@@ -1362,6 +1362,6 @@ LiveInterval LiveIntervals::createInterval(unsigned reg) { float Weight = MRegisterInfo::isPhysicalRegister(reg) ?- (float)HUGE_VAL : 0.0F;+ HUGE_VALF : 0.0F; return LiveInterval(reg, Weight); }Index: llvm/lib/CodeGen/RegAllocLinearScan.cppdiff -u llvm/lib/CodeGen/RegAllocLinearScan.cpp:1.129 llvm/lib/CodeGen/RegAllocLinearScan.cpp:1.130--- llvm/lib/CodeGen/RegAllocLinearScan.cpp:1.129 Tue Oct 24 09:35:25 2006+++ llvm/lib/CodeGen/RegAllocLinearScan.cpp Tue Nov 7 06:25:45 2006@@ -545,7 +545,7 @@ DEBUG(std::cerr "\tassigning stack slot at interval " *cur ":\n"); // Find a register to spill.- float minWeight = float(HUGE_VAL);+ float minWeight = HUGE_VALF; unsigned minReg = 0; for (TargetRegisterClass::iterator i = RC-allocation_order_begin(*mf_), e = RC-allocation_order_end(*mf_); i != e; ++i) {@@ -582,7 +582,7 @@ // if the current has the minimum weight, we need to spill it and // add any added intervals back to unhandled, and restart // linearscan.- if (cur-weight != float(HUGE_VAL) cur-weight = minWeight) {+ if (cur-weight != HUGE_VALF cur-weight = minWeight) { DEBUG(std::cerr "\t\t\tspilling(c): " *cur '\n';); int slot = vrm_-assignVirt2StackSlot(cur-reg); std::vectorLiveInterval* added =___llvm-commits mailing listllvm-commits@cs.uiuc.eduhttp://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
smime.p7s
Description: S/MIME cryptographic signature
___
llvm-commits mailing list
llvm-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
Re: [llvm-commits] CVS: llvm/lib/CodeGen/LiveIntervalAnalysis.cpp RegAllocLinearScan.cpp
John,Adding declaration to DataTypes.h(.in).Cheers,-- JimOn Nov 8, 2006, at 12:30 PM, Jim Laskey wrote:John,Both are defined on Darwin, FLT_MAX in float.h and HUGE_VALF in math.h. However, neither header seems to be based on a BSD header. I choose HUGE_VALF because it was also defined in the LINUX and FREEBSD math.h headers (seemed like confirmation to me.) I'll wait for Chris to make the call. (might uses a #ifndef HUGE_VALF thingame.)Cheers,-- JimOn Nov 8, 2006, at 12:03 PM, John Criswell wrote:Dear Mr. Laskey,This change broke the LLVM build on OpenBSD. Would it be possible touse FLT_MAX instead of HUGE_VALF? FLT_MAX from float.h looks more portable.-- John T.Jim Laskey wrote: Changes in directory llvm/lib/CodeGen:LiveIntervalAnalysis.cpp updated: 1.190 - 1.191RegAllocLinearScan.cpp updated: 1.129 - 1.130---Log message:Use correct value for float HUGH_VAL.---Diffs of the changes: (+6 -6) LiveIntervalAnalysis.cpp | 8 RegAllocLinearScan.cpp | 4 ++-- 2 files changed, 6 insertions(+), 6 deletions(-)Index: llvm/lib/CodeGen/LiveIntervalAnalysis.cppdiff -u llvm/lib/CodeGen/LiveIntervalAnalysis.cpp:1.190 llvm/lib/CodeGen/LiveIntervalAnalysis.cpp:1.191--- llvm/lib/CodeGen/LiveIntervalAnalysis.cpp:1.190 Tue Nov 7 01:18:40 2006+++ llvm/lib/CodeGen/LiveIntervalAnalysis.cpp Tue Nov 7 06:25:45 2006@@ -219,7 +219,7 @@ // range the use follows def immediately, it doesn't make sense to spill // it and hope it will be easier to allocate for this li. if (isZeroLengthInterval(LI))- LI.weight = float(HUGE_VAL);+ LI.weight = HUGE_VALF; if (EnableReweight) { // Divide the weight of the interval by its size. This encourages @@ -265,7 +265,7 @@ std::vectorLiveInterval* added;- assert(li.weight != HUGE_VAL + assert(li.weight != HUGE_VALF "attempt to spill already spilled interval!"); DEBUG(std::cerr "\t\t\t\tadding intervals for spills for interval: ";@@ -340,7 +340,7 @@ // the spill weight is now infinity as it // cannot be spilled again- nI.weight = float(HUGE_VAL);+ nI.weight = HUGE_VALF; if (HasUse) { LiveRange LR(getLoadIndex(index), getUseIndex(index),@@ -1362,6 +1362,6 @@ LiveInterval LiveIntervals::createInterval(unsigned reg) { float Weight = MRegisterInfo::isPhysicalRegister(reg) ?- (float)HUGE_VAL : 0.0F;+ HUGE_VALF : 0.0F; return LiveInterval(reg, Weight); }Index: llvm/lib/CodeGen/RegAllocLinearScan.cppdiff -u llvm/lib/CodeGen/RegAllocLinearScan.cpp:1.129 llvm/lib/CodeGen/RegAllocLinearScan.cpp:1.130--- llvm/lib/CodeGen/RegAllocLinearScan.cpp:1.129 Tue Oct 24 09:35:25 2006+++ llvm/lib/CodeGen/RegAllocLinearScan.cpp Tue Nov 7 06:25:45 2006@@ -545,7 +545,7 @@ DEBUG(std::cerr "\tassigning stack slot at interval " *cur ":\n"); // Find a register to spill.- float minWeight = float(HUGE_VAL);+ float minWeight = HUGE_VALF; unsigned minReg = 0; for (TargetRegisterClass::iterator i = RC-allocation_order_begin(*mf_), e = RC-allocation_order_end(*mf_); i != e; ++i) {@@ -582,7 +582,7 @@ // if the current has the minimum weight, we need to spill it and // add any added intervals back to unhandled, and restart // linearscan.- if (cur-weight != float(HUGE_VAL) cur-weight = minWeight) {+ if (cur-weight != HUGE_VALF cur-weight = minWeight) { DEBUG(std::cerr "\t\t\tspilling(c): " *cur '\n';); int slot = vrm_-assignVirt2StackSlot(cur-reg); std::vectorLiveInterval* added =___llvm-commits mailing listllvm-commits@cs.uiuc.eduhttp://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits ___llvm-commits mailing listllvm-commits@cs.uiuc.eduhttp://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
smime.p7s
Description: S/MIME cryptographic signature
___
llvm-commits mailing list
llvm-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
Re: [llvm-commits] CVS: llvm/lib/CodeGen/LiveIntervalAnalysis.cpp RegAllocLinearScan.cpp
On 11/8/06, Jim Laskey [EMAIL PROTECTED] wrote: John, Both are defined on Darwin, FLT_MAX in float.h and HUGE_VALF in math.h. However, neither header seems to be based on a BSD header. I choose HUGE_VALF because it was also defined in the LINUX and FREEBSD math.h headers (seemed like confirmation to me.) I'll wait for Chris to make the call. (might uses a #ifndef HUGE_VALF thingame.) Would it be possible to use std::numeric_limitsfloat::infinity in limits instead? -bw ___ llvm-commits mailing list llvm-commits@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
Re: [llvm-commits] CVS: llvm/lib/CodeGen/LiveIntervalAnalysis.cpp RegAllocLinearScan.cpp
On Nov 8, 2006, at 9:24 AM, Bill Wendling wrote: On 11/8/06, Jim Laskey [EMAIL PROTECTED] wrote: John, Both are defined on Darwin, FLT_MAX in float.h and HUGE_VALF in math.h. However, neither header seems to be based on a BSD header. I choose HUGE_VALF because it was also defined in the LINUX and FREEBSD math.h headers (seemed like confirmation to me.) I'll wait for Chris to make the call. (might uses a #ifndef HUGE_VALF thingame.) Would it be possible to use std::numeric_limitsfloat::infinity in limits instead? I think that had some other problems, it is broken in some version of GCC, IIRC. -Chris ___ llvm-commits mailing list llvm-commits@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
