llvm dev - Feb 2018 - 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


On 2/13/2018 3:11 AM, Jesper Antonsson via llvm-dev
wrote:
> 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
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
> 
-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, 
hosted by The Linux Foundation

> On Feb 13, 2018, at 1:11 AM, Jesper Antonsson via llvm-dev <llvm-dev at
lists.llvm.org> wrote:
> 
> 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