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::map<unsigned, 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 (1<<18)
>> 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
