[llvm-commits] [llvm] r56384 - in /llvm/trunk/lib/CodeGen: RegAllocLinearScan.cpp SimpleRegisterCoalescing.cpp

[Evan Cheng]

On Sep 22, 2008, at 8:45 AM, Chris Lattner wrote:

> On Sep 21, 2008, at 11:52 PM, Evan Cheng wrote:
>> On Sep 21, 2008, at 11:19 PM, Chris Lattner wrote:
>>> On Sep 21, 2008, at 11:17 PM, Evan Cheng wrote:
>>>>>> While that's the correct approach, it breaks all kinds of
>>>>>> assumptions
>>>>>> in liveintervals and the coalescer. It will make the problem much
>>>>>> more
>>>>>> complicated. I don't think it's worth the effort.
>>>>>
>>>>> What sorts of assumptions?
>>>>
>>>> That use must be 1 cycle after instruction cycle, def must be 2
>>>> cycles
>>>> after it.
>>>
>>> What code makes this sort of assumption?  It seems fragile.
>>
>> It's all over the place in coalescer. I'd prefer to fix it only when
>> it's necessary. Not for early clobber.
>
> Can you give me an example?  It sounds like these sorts of assumptions
> are exactly what we want: you can only coalesce a def/use of a copy if
> the live ranges exactly line up.  Overlapping by one slot is a *good*
> thing because we want to prevent coalescing.

e.g.
       // Figure out the value # from the RHS.
       LHSValsDefinedFromRHS[VNI]=RHS.getLiveRangeContaining(VNI- 
 >def-1)->valno;

Ok, so most of the assertions are for copies:

   LiveInterval::iterator BLR = IntB.FindLiveRangeContaining(CopyIdx);
   if (BLR == IntB.end()) // Should never happen!
     return false;
   VNInfo *BValNo = BLR->valno;

   // Get the location that B is defined at.  Two options: either this  
value has
   // an unknown definition point or it is defined at CopyIdx.  If  
unknown, we
   // can't process it.
   if (!BValNo->copy) return false;
   assert(BValNo->def == CopyIdx && "Copy doesn't define the value?");

But it is possible modeling the def this way will *just work*. I doubt  
it, but it's worth experimenting.

>
>
>>>>> Then you'd have to mark $out0 as being an early clobber, because  
>>>>> it
>>>>> is
>>>>> stored to before $in2 is read.
>>>>
>>>> Ewwww.
>>>
>>> Eww what? You don't like asms with multiple instructions?  Or you
>>> prefer CPUs that have instructions that would require this? ;-)
>>
>> Ewww multi- instruction asm with this horribleness.
>>
>> Some in-order execution cpu's may require this. Usually it would
>> require HW bypass for reads to completed early enough for def to
>> target the same registers. It's quite common for some instructions to
>> not have the benefit of bypass in some in-order machines.
>
> Can earlyclobber operands be used to model the armv4 "mul" register
> weirdness where the input and output regs can't be the same?

We could, but the correct way to model it is to push the use down one  
cycle, not def up one cycle. The problem with early clobber is the def  
cannot overlap any of the uses (both Rm and Rs). In the ARM mul case,  
the def cannot overlap Rm only.

Evan

>
>
> -Chris
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits