llvm dev - Nov 2019 - Question about physical registers in ISel

Hi all,

I need to figure out why InstrEmitter::EmitMachineNode assumes that when
the number of outputs of a MachineSDNode is greater than the number of defs
in the corresponding MCInstrDesc, the outputs in the difference will be
placed into physical registers as opposed to virtual registers.

The specific line in question is:
    bool HasPhysRegOuts = NumResults > NumDefs &&
II.getImplicitDefs()!=nullptr;

Where NumResults is the number of outputs in the MachineSDNode and NumDefs
comes from the MCInstrDesc and ultimately the TableGen definition of the
instruction. I do not know why this assumption is made or what code depends
on it, but it is over 12 years old:
https://github.com/llvm/llvm-project/commit/c5549fc3a055710a3958a5b3164db3fa167c720c#diff-9dfdb934cb2b01ba001da4bbf3c5cb3cR632
.

The context for this question is that I am trying to implement an
instruction for the WebAssembly backend that returns a variable number of
operands. I am following the example of ARM's load multiple instructions,
but this assertion in the instruction emitter is causing problems because
WebAssembly, unlike ARM, does not use physical registers at all. Also,
almost all WebAssembly instructions have an implicit def of the register
that represents the argument stack, so II.getImplicitDefs() is necessarily
non-null.

I am open to ideas about the best way forward. I am currently thinking that
if this assumption is important for most targets, I might need to add a new
bit to MCInstrDesc to disable this assumption.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20191118/e11c1d4d/attachment.html>

Hi Thomas,

The reason is simply because an implicit def of a virtual register doesn’t make
sense in theory.

The rationale is let say that an instruction implicitly defines a virtual
register. The implicit aspect of it means that this information cannot be
“seen”. Thus, when we finally emit the instruction, there is nothing in the
encoding or anywhere that is going to tell where the value has been physically
defined.

The only way something is implicitly defined is when everybody knows where the
value is going to end up and that’s only achievable in a physical register.

Cheers,
-Quentin
> On Nov 18, 2019, at 6:21 PM, Thomas Lively via llvm-dev <llvm-dev at
lists.llvm.org> wrote:
> 
> Hi all,
> 
> I need to figure out why InstrEmitter::EmitMachineNode assumes that when
the number of outputs of a MachineSDNode is greater than the number of defs in
the corresponding MCInstrDesc, the outputs in the difference will be placed into
physical registers as opposed to virtual registers.
> 
> The specific line in question is:
>     bool HasPhysRegOuts = NumResults > NumDefs &&
II.getImplicitDefs()!=nullptr;
> 
> Where NumResults is the number of outputs in the MachineSDNode and NumDefs
comes from the MCInstrDesc and ultimately the TableGen definition of the
instruction. I do not know why this assumption is made or what code depends on
it, but it is over 12 years old:
https://github.com/llvm/llvm-project/commit/c5549fc3a055710a3958a5b3164db3fa167c720c#diff-9dfdb934cb2b01ba001da4bbf3c5cb3cR632
<https://github.com/llvm/llvm-project/commit/c5549fc3a055710a3958a5b3164db3fa167c720c#diff-9dfdb934cb2b01ba001da4bbf3c5cb3cR632>.
> 
> The context for this question is that I am trying to implement an
instruction for the WebAssembly backend that returns a variable number of
operands. I am following the example of ARM's load multiple instructions,
but this assertion in the instruction emitter is causing problems because
WebAssembly, unlike ARM, does not use physical registers at all. Also, almost
all WebAssembly instructions have an implicit def of the register that
represents the argument stack, so II.getImplicitDefs() is necessarily non-null.
> 
> I am open to ideas about the best way forward. I am currently thinking that
if this assumption is important for most targets, I might need to add a new bit
to MCInstrDesc to disable this assumption.
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20191118/070709d4/attachment.html>

Hi Quentin,

Thanks, that explanation makes sense. I can see that in a normal register
machine, implicitly defs must be physical registers. In a stack machine
like WebAssembly, though, implicit defs are known to be pushed onto the
value stack just like any other defs. Slots on the value stack are
represented by virtual registers until stackification, so for WebAssembly
we do need the implicit defs to be stored in virtual registers. I guess the
best thing to do for now would be to add a bit to the MCInstrDesc carrying
this information.

Thomas

On Mon, Nov 18, 2019 at 6:53 PM Quentin Colombet <qcolombet at apple.com>
wrote:
> Hi Thomas,
>
> The reason is simply because an implicit def of a virtual register doesn’t
> make sense in theory.
>
> The rationale is let say that an instruction implicitly defines a virtual
> register. The implicit aspect of it means that this information cannot be
> “seen”. Thus, when we finally emit the instruction, there is nothing in the
> encoding or anywhere that is going to tell where the value has been
> physically defined.
>
> The only way something is implicitly defined is when everybody knows where
> the value is going to end up and that’s only achievable in a physical
> register.
>
> Cheers,
> -Quentin
>
> On Nov 18, 2019, at 6:21 PM, Thomas Lively via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
>
> Hi all,
>
> I need to figure out why InstrEmitter::EmitMachineNode assumes that when
> the number of outputs of a MachineSDNode is greater than the number of defs
> in the corresponding MCInstrDesc, the outputs in the difference will be
> placed into physical registers as opposed to virtual registers.
>
> The specific line in question is:
>     bool HasPhysRegOuts = NumResults > NumDefs &&
> II.getImplicitDefs()!=nullptr;
>
> Where NumResults is the number of outputs in the MachineSDNode and NumDefs
> comes from the MCInstrDesc and ultimately the TableGen definition of the
> instruction. I do not know why this assumption is made or what code depends
> on it, but it is over 12 years old:
>
https://github.com/llvm/llvm-project/commit/c5549fc3a055710a3958a5b3164db3fa167c720c#diff-9dfdb934cb2b01ba001da4bbf3c5cb3cR632
> .
>
> The context for this question is that I am trying to implement an
> instruction for the WebAssembly backend that returns a variable number of
> operands. I am following the example of ARM's load multiple
instructions,
> but this assertion in the instruction emitter is causing problems because
> WebAssembly, unlike ARM, does not use physical registers at all. Also,
> almost all WebAssembly instructions have an implicit def of the register
> that represents the argument stack, so II.getImplicitDefs() is necessarily
> non-null.
>
> I am open to ideas about the best way forward. I am currently thinking
> that if this assumption is important for most targets, I might need to add
> a new bit to MCInstrDesc to disable this assumption.
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20191118/e16e4cb0/attachment-0001.html>