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

[Chris Lattner]

On Sep 22, 2008, at 10:28 AM, Evan Cheng wrote:
>> 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:
> But it is possible modeling the def this way will *just work*. I doubt
> it, but it's worth experimenting.

I would strongly prefer this.  Even if there are cases that don't  
"just work", I think this is the correct way to model it, and the  
right long-term answer.

>> 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.

Sure, I agree with that.  This is also true of most inline asms with  
multiple instructions (like the example I gave).  Using earlyclobber  
should be a conservative but correct solution (and much better than  
using the 'multiply fixer' pass that used to exist).

This would also make it easier to test that earlyclobber is working  
right (multiplies are more frequent than & in asms), which is why I  
brought it up. :)

-Chris