[llvm-commits] Fwd: [llvm] r48223 - in /llvm/trunk/lib: CodeGen/LowerSubregs.cpp CodeGen/SelectionDAG/ScheduleDAG.cpp Target/Target.td Target/X86/X86ISelDAGToDAG.cpp Target/X86/X86InstrInfo.h Target/X86/X86InstrInfo.td Target/X86/X86RegisterInfo.h Target/X86/X86RegisterInfo.td

[Evan Cheng]

On Mar 14, 2008, at 10:52 AM, Chris Lattner wrote:

>>>> vr1024 = insert_subreg undef, vr1025, x86_subreg32bit
>>>
>>> This doesn't work because it breaks the invariant that the first
>>> operand is a register class.
>>
>> Huh? You are talking about insert_subreg or in general? Can't be the
>> case in general.
>
> insert_subreg.
>
>>>> Why not:
>>>
>>> vr1027 = implicit_def
>>> vr1024 = insert_subreg vr1027, vr1025, x86_subreg32bit
>>>
>>> We already have implicit_def, so this reduce the number of concepts
>>> the code generator has to know about.
>>
>> This will prevent coalescing. insert_subreg should be a two address
>> instruction:
>>
>> vr1027 = implicit_def
>> vr1027 = insert_subreg vr1027, vr1025, x86_subreg32bit
>>
>> vr1027 and vr1025 live intervals conflict.
>
> the register allocator should, but doesn't, treat implicit_def
> specially already.  Live ranges that are defined by an implicit_def
> should just be dropped making this a moot point :)

Yes, that would be a useful optimization except 1) it's yet another  
target specific hook or target instruction property since isel will  
turn ISD::UNDEF into a target instruction, 2) if implicit_def isn't  
coalesced away (as it's used in many other cases) it needs to be  
assigned a register which implies it should define a live interval.

#1 can be easily fixed. #2 can also be fixed by treating "an  
implicit_def used by a two-address instruction" a special case. I am  
not sure it's quite that easy. Besides, it doesn't help with x86-64  
zero extension case (I would like to find another solution for that,  
not sure if it should be coalescer's job to deal with it).

Evan

>
>
>> Let's make sure we agree or disagree on whether insert_subreg is a  
>> two
>> address instruction. To me, it's natural and makes practical sense.
>> After all, insert_subreg means read / modify / write, it should not
>> create a *new* register.
>
> I agree.
>
> -Chris
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits