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

[Jakob Stoklund Olesen]

On 04/08/2009, at 19.31, Evan Cheng wrote:
> I am very hesitant to change the semantics. That will break a lot of
> assumptions in the register allocator. I think the current approach of
> having subreg lowering pass insert the right instructions to model
> "kill" is enough. Is it not?

You are probably right. I am still struggling to completely understand  
the semantics.

We will almost certainly need to insert fake instructions that only  
change flags. I am using IMPLICIT_DEF for that now, but it should  
probably be replaced by a new ALTER_LIFE or something.

[...]

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

Ok, so if I understand you correctly, the actual register doesn't  
really matter. It is only there so we produce valid machine code and  
the only restriction is that the register class must be correct. And  
of course there are two-address constraints.

If that is correct, we could write an undef operand as %UNDEF. Like  
this:

     %R0<def> = INSERT_SUBREG %UNDEF, %R0L<kill>, 1

This makes sense to me. Note that in this case %R0 must be dead. Not  
because it is referenced by an <undef>, but because it is not killed  
before being defined.

MachineInstr::addRegisterKilled() should not remove the <undef> flag.  
It should completely skip the undef operand, just like the  
regscavenger does.

The flags <kill> and <undef> should not be allowed at the same time.  
It is nonsensical.

Am I on the right track?