llvm dev - Dec 2017 - Canonical way to handle zero registers?

Thanks! That looks like a winning approach.

I swear I grepped around for ISD::Constant but for some reason never found
this code. I think maybe I was searching for ISD::Constant with
setOperationAction, which in hindsight was narrowing down my search to just
lowering, which is exactly what I didn't want! (I was looking for other
approaches). I also tried looking in depth at PowerPC but it looks like it
doesn't use this approach either.

-- Sean Silva


On Dec 24, 2017 12:16 AM, "Alex Bradbury" <asb at
asbradbury.org> wrote:

On 24 December 2017 at 04:43, Sean Silva via llvm-dev
<llvm-dev at lists.llvm.org> wrote:
> Thanks, that sounds like it would work. Was this based on what any other
> target did? Or do any other targets take this approach?
>
> I just want to make sure that we don't already have a hook suitable for
> this. Overriding runOnFunction to run what could be described as just a
> "late SelectionDAG pass" sounds pretty intrusive. Do you remember
other
> approaches that didn't work?
An obvious approach that doesn't work: just writing a pattern. This
causes assertions, seemingly as some code paths don't like the
introduction of a physical register.

At least AArch64, Lanai, and RISC-V handle the zero register in
TgtDAGToDAGISel::Select. Lanai also has a "-1" register and handles
that case in the same place.

Copying from LanaiDAGToDAGISel::Select:

  EVT VT = Node->getValueType(0);
  switch (Opcode) {
  case ISD::Constant:
    if (VT == MVT::i32) {
      ConstantSDNode *ConstNode = cast<ConstantSDNode>(Node);
      // Materialize zero constants as copies from R0. This allows the
coalescer
      // to propagate these into other instructions.
      if (ConstNode->isNullValue()) {
        SDValue New = CurDAG->getCopyFromReg(CurDAG->getEntryNode(),
                                             SDLoc(Node), Lanai::R0,
MVT::i32);
        return ReplaceNode(Node, New.getNode());
      }
      // Materialize all ones constants as copies from R1. This allows the
      // coalescer to propagate these into other instructions.
      if (ConstNode->isAllOnesValue()) {
        SDValue New = CurDAG->getCopyFromReg(CurDAG->getEntryNode(),
                                             SDLoc(Node), Lanai::R1,
MVT::i32);
        return ReplaceNode(Node, New.getNode());
      }
    }
    break;



Best,

Alex
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20171226/c03c4e28/attachment.html>

> On Dec 26, 2017, at 18:42, Sean Silva via llvm-dev <llvm-dev at
lists.llvm.org> wrote:
> 
> Thanks! That looks like a winning approach.
> 
> I swear I grepped around for ISD::Constant but for some reason never found
this code. I think maybe I was searching for ISD::Constant with
setOperationAction, which in hindsight was narrowing down my search to just
lowering, which is exactly what I didn't want! (I was looking for other
approaches). I also tried looking in depth at PowerPC but it looks like it
doesn't use this approach either.
> 
> -- Sean Silva
What’s the reason for trying to handle this in SelectionDAG at all? I would just
materialize zero like any other constant, and treat replacing that with the zero
register as an immediate folding optimization (e.g. FoldImmediate or another
peephole pass)

-Matt

On Dec 27, 2017 2:00 PM, "Matt Arsenault" <arsenm2 at gmail.com>
wrote:


> On Dec 26, 2017, at 18:42, Sean Silva via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
>
> Thanks! That looks like a winning approach.
>
> I swear I grepped around for ISD::Constant but for some reason never
found this code. I think maybe I was searching for ISD::Constant with
setOperationAction, which in hindsight was narrowing down my search to just
lowering, which is exactly what I didn't want! (I was looking for other
approaches). I also tried looking in depth at PowerPC but it looks like it
doesn't use this approach either.
>
> -- Sean Silva
What’s the reason for trying to handle this in SelectionDAG at all? I would
just materialize zero like any other constant, and treat replacing that
with the zero register as an immediate folding optimization (e.g.
FoldImmediate or another peephole pass)


I thought about doing that, but I wasn't sure I could make it work.

The issue is that the hardwired registers are actually the only way to
write immediates of this register class (the registers are very small,
obviously). I've been phrasing this as integer 0 (and -1) to keep the
discussion closer to other architectures, but the fact that these hardwired
registers are the only way to reference immediates of this register class
is one important difference.

One thing I've been curious about is how immediates interact with register
classes. Could we use ordinary immediate MachineOperand's (of the
appropriate bit width) and just print the immediate MO's of this register
class as the corresponding hardwired register? Does MIR have any
constraints on using an immediate MO instead of a register?

-- Sean Silva


-Matt
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20171228/2df4dabc/attachment.html>