[llvm-dev] Canonical way to handle zero registers?

[Sean Silva via llvm-dev]

On Tue, Jan 2, 2018 at 8:28 AM, Daniel Sanders <daniel_l_sanders at apple.com>
wrote:

> Hi Sean,
>
> Just to give the GlobalISel perspective on this,


Thanks for chiming in!


> GlobalISel supports the declaration of a zero register in the register
> class like so:
>         def GPR32z : RegisterOperand<GPR32> {
>           let GIZeroRegister = WZR;
>         }
> With that definition, the tablegen-erated ISel code will try to replace
> will try to replace 'G_CONSTANT s32 0' with WZR whenever the operand is
> specified as GPR32z.
>


Is this method extensible to the case of other hardwired register values?
Tracing through the code, I noticed that it seems to boil down to a
GIR_CopyOrAddZeroReg opcode, which seems like a pretty deep embedding of
the specialness of zero.

Also, IIUC, GPR32z is defining a special reg class that enables the
zero-register transformation. Defining a new reg class seems pretty
heavyweight for this; is there ever a situation where you wouldn't want the
zero-register transformation to fire so you could just put this on GPR32
itself? I noticed that there actually aren't very many uses of GPR32z which
seems strange, as I would expect most instructions could make use of the
zero register.

Thanks,

-- Sean Silva


>
> > On 21 Dec 2017, at 21:22, Sean Silva via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
> >
> > I looked around the codebase and didn't see anything that obviously
> looked like the natural place to turn constant zero immediates into
> zero-registers (i.e. registers that always return zero when read). Right
> now we are expanding them in ISelLowering::LowerOperation but that seems
> too early.
> >
> > The specific issue I'm hitting is that we have a register that reads as
> -1 and so when we replace -1 too early with this register, the standard
> "not" pattern (xor x, -1) will fail to match to "not".
> >
> > Thanks,
> > Sean Silva
> > _______________________________________________
> > LLVM Developers mailing list
> > llvm-dev at lists.llvm.org
> > http://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/20180103/ddba9364/attachment.html>