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

Sean Silva via llvm-dev llvm-dev at lists.llvm.org
Thu Jan 4 13:19:23 PST 2018


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>


More information about the llvm-dev mailing list