[llvm-commits] [llvm] r59266 - in /llvm/trunk: include/llvm/Target/TargetLowering.h lib/Target/X86/X86ISelLowering.cpp lib/Target/X86/X86RegisterInfo.td

Evan Cheng evan.cheng at apple.com
Sat Nov 15 01:07:11 PST 2008



On Nov 14, 2008, at 10:02 AM, Dale Johannesen <dalej at apple.com> wrote:

>
> On Nov 13, 2008, at 10:48 PMPST, Chris Lattner wrote:
>> This is a very creative way to solve this problem.  A couple
>> questions:
>>
>>> +// A class to support the 'A' assembler constraint: EAX then EDX.
>>> +def GRAD : RegisterClass<"X86", [i32], 32, [EAX, EDX]> {
>>> +  let MethodProtos = [{
>>> +    iterator allocation_order_begin(const MachineFunction &MF)
>>> const;
>>> +    iterator allocation_order_end(const MachineFunction &MF) const;
>>> +  }];
>>> +
>>> +  let MethodBodies = [{
>>> +     static const unsigned X86_GRAD_AO[] = {X86::EAX, X86::EDX};
>>> +   GRADClass::iterator
>>> +    GRADClass::allocation_order_begin(const MachineFunction &MF)
>>> const {
>>> +      return X86_GRAD_AO;
>>> +    }
>>> +
>>> +    GRADClass::iterator
>>> +    GRADClass::allocation_order_end(const MachineFunction &MF)
>>> const {
>>> +      return X86_GRAD_AO + (sizeof(X86_GRAD_AO) /  
>>> sizeof(unsigned));
>>> +    }
>>> +  }];
>>> +}
>>> +
>>
>> I think you can drop all the custom code and just have:
>> def GRAD : RegisterClass<"X86", [i32], 32, [EAX, EDX]>;
>> The custom code is only needed when you don't want to be able to
>> allocate all regs from the class.
>
> OK.
>
>> Did you measure the compile time impact of this?
>
> No.  Surely unreferenced register classes aren't that inefficient?

Right. Adding register classes doesn't affect allocation much. It's  
only a concern if more register aliases are added.

Evan

>
>
>> Does llc slow down
>> at "-O0" by adding another register class?
>
>> Finally, how does this fix the bug?  Is isel still doing the  
>> 'register
>> allocation' of the 'A' constraint, or is it turning it into vregs  
>> from
>> the GRAD reg class?  I thought the bug was that the isel regalloc was
>> assigning the tied register to EAX and then it just wasn't available
>> when handling the A constraint.
>
>
> ISel is allocating the registers for both arguments before and after
> the patch.  Since 'A' and the tied register were both previously
> treated as C_RegisterClass, they were allocated in argument order,
> which led to the problem you say.  Now that 'A' is marked as using a
> specific hard register, it gets allocated before the tied register,
> which then knows it cannot use EAX and EDX.
>
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits



More information about the llvm-commits mailing list