[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 clattner at apple.com
Fri Mar 14 10:52:33 PDT 2008

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


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


More information about the llvm-commits mailing list