[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 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.
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
More information about the llvm-commits