[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 evan.cheng at apple.com
Fri Mar 14 14:47:11 PDT 2008


On Mar 14, 2008, at 2:09 PM, Chris Lattner wrote:

>>>> 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 :)
>>
>> Yes, that would be a useful optimization except 1) it's yet another
>> target specific hook or target instruction property since isel will
>> turn ISD::UNDEF into a target instruction,
>
> If you make it a "target-independent instruction", then:
>
> a) targets don't need to specify how to match undef
> b) we get rid of the existing "is implicit_def" flag
> c) we eliminate the need to have one "implicit_def instruction" per
> register class.

Ok. This *should* work.

>
>
>> 2) if implicit_def isn't
>> coalesced away (as it's used in many other cases) it needs to be
>> assigned a register which implies it should define a live interval.
>
>> #1 can be easily fixed. #2 can also be fixed by treating "an
>> implicit_def used by a two-address instruction" a special case. I am
>> not sure it's quite that easy. Besides, it doesn't help with x86-64
>> zero extension case (I would like to find another solution for that,
>> not sure if it should be coalescer's job to deal with it).
>
> I'm not sure what you mean here.  Consider if you have ('x' is a vreg
> for example):
>
> 1. x = ...
> 2. y = IMPLICIT_DEF
> 3. ...
> 4. z = y + x   <- 2 address instruction
>
> today, the live range of y is [2,4] and x is [1..4].  You're right
> that they conflict.
>
> However, I'm suggesting that somewhere in regalloc (live interval
> analysis?) a LiveInterval for y is created.  Currently it is [2,4].
> I'm suggesting the LiveInterval analysis (or something else in RA
> land) sees that the defining instruction for the live interval is an
> implicit def.  As such, it would just discard the live range and nuke
> the instruction.  The LiveInterval would still exist, it would just be
> empty.   Because it is empty, it can't conflict with anything.

Zero length liveinterval is an interesting idea. There is a  
possibility this make break some assumptions in the backend. We'll  
see. I'll poke at this.

Evan

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




More information about the llvm-commits mailing list