[llvm-commits] [llvm] r77989 - in /llvm/trunk: lib/CodeGen/LowerSubregs.cpp lib/CodeGen/MachineInstr.cpp test/CodeGen/ARM/2009-08-02-RegScavengerAssert-Neon.ll

[Evan Cheng]

On Aug 3, 2009, at 11:05 PM, Jakob Stoklund Olesen wrote:

>
> On 03/08/2009, at 23.40, Evan Cheng wrote:
>
>>> Finally, clear the undef flag in MachineInstr::addRegisterKilled.
>>> Undef implies dead and kill implies live, so they cant both be  
>>> valid.
>>
>> That's not necessary. Undef doesn't implies dead. It just means its
>> garbage and it has no liveness.
>
> A zombie!?
>
> I am not sure what you mean.
> Do you mean that a register can have three states: dead-live-undef?
> Or do you mean that an undef operand can be both dead or live, both
> are OK?

Undef operands are "don't care". :-) It would have been cleaner to  
have an Undef machineoperand rather than a register machineoperand  
that's undef. But we still need to assign registers to them so the  
instructions can be translated to machine code.

>
> Consider this replacement in lower-subregs:
>
> From: %R0<def> = INSERT_SUBREG %R0<undef>, %R0L<kill>, 1
> To: %R0<def> = IMPLICIT_DEF %R0L<imp-use,kill>
>
> That is what we currently do, and it works when undef implies dead. If
> undef implies "don't know", we need to do this instead:
>
> To: %R0<def> = IMPLICIT_DEF %R0<imp-use,kill,undef>
>
> This won't work today, because the scavenger ignores all undef
> operands, and we would get a double-def on %R0L. We could fix the
> scavenger to also kill <kill,undef> operands. But that means that
> <kill,undef> would work just like <imp-kill> did before: Kill this
> register, dead or alive.

I see. subreg lowering could have just remove the undef marker. What  
my comment meant was addRegisterKilled really didn't have to unset the  
undef marker. It needed to be removed in this special case. I think a  
cleaner solution would have been to introduce a target specific  
instruction KILL that just kills a register. But that's future work.

>
> I am not sure is RegScavenger::backward() is used today, but I think
> it can only work if we stick to strict rules. What would the state of
> %R0 be after running backward() over an IMPLICIT_DEF like the one  
> above?

I agree in this case the undef marker must be removed. The only  
argument who should remove it.

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