[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
clattner at apple.com
Fri Mar 14 10:32:35 PDT 2008
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.
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.
More information about the llvm-commits