[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

[Evan Cheng]

On Mar 14, 2008, at 10:56 AM, Chris Lattner wrote:

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

I agree with this in general although I am not certain of the  
implementation complexity.

vr1024 = undef
...
...
vr1025 = op vr1024, ?

How would we model vr1024? A single cycle live interval? Or better  
yet, don't allocate it and let rewriter assign it an arbitrary  
register? That seems like goodness to me.

>
>
> This is orthogonal from the subreg stuff of course.

Yep.

Evan
>
>
> -Chris
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits