[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 14:09:02 PDT 2008


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

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



-Chris



More information about the llvm-commits mailing list