[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:56:58 PDT 2008

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

To expand on this, I think that IMPLICIT_DEF should become a target  
independent opcode like PHI or INLINE_ASM.  The sole purpose of  
IMPLICIT_DEF is to satisfy SSA properties of SSA values need a  
definition.  As such, I consider them to be an artifact of SSA, like  
PHI nodes.  I think it is entirely reasonable for "the register  
allocator" to delete these things when it "converts out of ssa".  I've  
seen many cases when live ranges from IMPLICIT_DEF end up eating a  
register (causing something to get spilled or an extra copy) and  
otherwise wreak havok.  Having "ssa elimination" just delete live  
ranges/value numbers that are defined by an IMPLICIT_DEF (and also  
deleting the IMPLICIT_DEF itself) seems like an easy and natural way  
to handle this.

This is orthogonal from the subreg stuff of course.


More information about the llvm-commits mailing list