Undef physical registers?

Hi,

I'm a bit unsure of the semantics of undef physical registers. The explanations I've seen in the code and in the langref seems to
pertain more to constant values and virtual registers.

What I really want to achieve is a push-pop of a register to have a temporary to work with, without having to check if this
register is defined or not. However, whenever the reg is not defined before the push, the MachineVerifier complains about that.

If I add RegState::Undef to the push, the verifier complaint goes away, but I worry that this might be unsafe. I would like
"Undef" for physical registers to mean "we don't care if this register has been defined or not", but perhaps it means "this
register can now have any bits set", so it'd be allowed to optimize the push away?

So, is the latter interpretation true, and if so, is there some other idiom that would allow me to push-pop a possibly undefined
physical register?

Thanks, Jesper

The "undef" flag on a use means that the use doesn't care about the value in that register. In terms of data-flow, it means that that use is not associated with any definitions. Liveness information simply ignores such uses.

The problem with "undef" uses is that they can be reordered with respect to other uses/definitions of that register. If the push instruction was also marked as clobbering the register, it could probably work, but it could still be optimized away. That could be prevented by marking the push instruction (you could create a separate pseudo-instruction for this) as having side-effects.

The best way to implement this would be to have a helper routine that inserts push/pop instructions only when the register is actually live in that range. Whether it's live or not can be checked using LivePhysRegs, so it wouldn't require a lot of new code.

-Krzysztof

Hi,

I'm a bit unsure of the semantics of undef physical registers. The explanations I've seen in the code and in the langref seems to
pertain more to constant values and virtual registers.

The LangRef talks about the llvm IR, not the representation used in the backend. The undef node in IR is something different from the machine operand flag named undef.

What I really want to achieve is a push-pop of a register to have a temporary to work with, without having to check if this
register is defined or not. However, whenever the reg is not defined before the push, the MachineVerifier complains about that.

It sounds like you may functionality that the register scavenger provides.

If I add RegState::Undef to the push, the verifier complaint goes away, but I worry that this might be unsafe. I would like
"Undef" for physical registers to mean "we don't care if this register has been defined or not", but perhaps it means "this
register can now have any bits set", so it'd be allowed to optimize the push away?

So, is the latter interpretation true, and if so, is there some other idiom that would allow me to push-pop a possibly undefined
physical register?

You can't blindly insert a push/store of a register without knowing whether it is alive or not. At least for targets that track liveness post register allocation which is nearly all of them nowadays.

I'd recommend using LiveRegUnits (or LivePhysRegs) to figure out whether a register is alive or not. If your pass is before or during PEI than you can also use the RegisterScavenger to do the spilling/restoring for you.

- Matthias