[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
clattner at apple.com
Fri Mar 14 14:51:19 PDT 2008
On Mar 14, 2008, at 2:47 PM, Evan Cheng wrote:
> 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.
Cool. This part can be done independently of the regalloc/modeling
>>> 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
>> 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.
I don't think it will eliminate the need to do all handling of it.
x = implicit_def
y = x
In theory, it would be nice to zap the y live range when coalescing x/
y. This could be done by seeing that x has no value numbers. This is
an (probably unimportant) optimization though.
More information about the llvm-commits