llvm dev - Jan 2018 - Canonical way to handle zero registers?

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>

> On 3 Jan 2018, at 19:44, Sean Silva <chisophugis at gmail.com> wrote:
> 
> 
> On Tue, Jan 2, 2018 at 8:28 AM, Daniel Sanders <daniel_l_sanders at
apple.com <mailto: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.
At the moment, zero is hardwired since losing an AArch64 optimization was the
motivating case behind adding it and the only other hardwired register I knew
about was Mips's $0 but I see no reason we couldn't expand on it with a
target hook of some kind.
> 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.
I haven't got around to rolling it out to GPR32 yet, we think it's safe
to do that but there are a couple instructions where wzr/xzr aren't
permitted. At the moment, it's on the instructions that lost the
optimization when tablegen took over from the C++.
> Thanks,
> 
> -- Sean Silva
>  
> 
> > On 21 Dec 2017, at 21:22, Sean Silva via llvm-dev <llvm-dev at
lists.llvm.org <mailto: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 <mailto:llvm-dev at lists.llvm.org>
> > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
<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/20180104/b4756186/attachment.html>

On Thu, Jan 4, 2018 at 7:59 AM, Daniel Sanders <daniel_l_sanders at
apple.com>
wrote:
>
>
> On 3 Jan 2018, at 19:44, Sean Silva <chisophugis at gmail.com> wrote:
>
>
> 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.
>
>
> At the moment, zero is hardwired since losing an AArch64 optimization was
> the motivating case behind adding it and the only other hardwired register
> I knew about was Mips's $0 but I see no reason we couldn't expand
on it
> with a target hook of some kind.
>
> 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.
>
>
> I haven't got around to rolling it out to GPR32 yet, we think it's
safe to
> do that but there are a couple instructions where wzr/xzr aren't
permitted.
> At the moment, it's on the instructions that lost the optimization when
> tablegen took over from the C++.
>
Makes sense, thanks for the explanation!

-- Sean Silva

>
> 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/20180104/568d452f/attachment.html>