[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.
-Chris
More information about the llvm-commits
mailing list