[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]

On Mar 14, 2008, at 10:02 AM, Evan Cheng wrote:

> Think about insert_subreg in the literal sense. It's modifying part  
> of a register. That is, the input and output super register must be  
> the same. Insert into zero would be modeled like this.
>
> vr1024 = mov 0
> vr1024 = insert_subreg vr1024, vr1025, x86_subreg32bit
>
> Ideally we model insert into undef the same way:
>
> vr1024 = insert_subreg undef, vr1025, x86_subreg32bit

This doesn't work because it breaks the invariant that the first  
operand is a register class.

> However, it's unclear what issues we would run into if insert_subreg  
> is a two address instruction.

Right, that is one effect.

> That's why I suggest making into into a separate insert_subreg_undef:
>
> vr1024 = insert_subreg_undef vr1025, x86_subreg32bit.

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.

-Chris