[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 11:06:09 PDT 2008
On Mar 14, 2008, at 10:52 AM, Chris Lattner wrote:
>>>> vr1024 = insert_subreg undef, vr1025, x86_subreg32bit
>>> This doesn't work because it breaks the invariant that the first
>>> operand is a register class.
>> Huh? You are talking about insert_subreg or in general? Can't be the
>> case in general.
>>>> Why not:
>>> vr1027 = implicit_def
>>> vr1024 = insert_subreg vr1027, vr1025, x86_subreg32bit
>>> 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
>> 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, 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).
>> Let's make sure we agree or disagree on whether insert_subreg is a
>> address instruction. To me, it's natural and makes practical sense.
>> After all, insert_subreg means read / modify / write, it should not
>> create a *new* register.
> I agree.
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
More information about the llvm-commits