[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

[Chris Lattner]

>>> 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 :)

> 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