Sean Silva via llvm-dev
2017-Dec-22 05:22 UTC
[llvm-dev] Canonical way to handle zero registers?
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 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20171221/975b1c10/attachment.html>
Simon Dardis via llvm-dev
2017-Dec-22 22:17 UTC
[llvm-dev] Canonical way to handle zero registers?
Hi Sean, Have you looked at inheriting from llvm:SelectionDAGISel for your target, invoking runOnMachineFunction to perform ISEL, then post processing the output by finding the cases where -1 is synthesized then used and replacing the uses of the synthesized -1 with the register wired to -1? The MIPS backend takes this approach for dealing with the zero register, see MipSEISelDAGToDAG.cpp for reference. Thanks, Simon ________________________________ From: llvm-dev [llvm-dev-bounces at lists.llvm.org] on behalf of Sean Silva via llvm-dev [llvm-dev at lists.llvm.org] Sent: Friday, December 22, 2017 5:22 AM To: llvm-dev Subject: [llvm-dev] Canonical way to handle zero registers? 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20171222/c5d8f77e/attachment.html>
Sean Silva via llvm-dev
2017-Dec-24 04:43 UTC
[llvm-dev] Canonical way to handle zero registers?
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? -- Sean Silva On Dec 22, 2017 2:17 PM, "Simon Dardis" <Simon.Dardis at mips.com> wrote:> Hi Sean, > > Have you looked at inheriting from llvm:SelectionDAGISel for your target, > invoking runOnMachineFunction to perform > ISEL, then post processing the output by finding the cases where -1 is > synthesized then used and replacing the uses > of the synthesized -1 with the register wired to -1? > > The MIPS backend takes this approach for dealing with the zero register, > see MipSEISelDAGToDAG.cpp for reference. > > Thanks, > Simon > ------------------------------ > *From:* llvm-dev [llvm-dev-bounces at lists.llvm.org] on behalf of Sean > Silva via llvm-dev [llvm-dev at lists.llvm.org] > *Sent:* Friday, December 22, 2017 5:22 AM > *To:* llvm-dev > *Subject:* [llvm-dev] Canonical way to handle zero registers? > > 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 >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20171223/9cfab693/attachment.html>
Daniel Sanders via llvm-dev
2018-Jan-02 16:28 UTC
[llvm-dev] Canonical way to handle zero registers?
Hi Sean, Just to give the GlobalISel perspective on this, 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.> 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
Sean Silva via llvm-dev
2018-Jan-04 03:44 UTC
[llvm-dev] 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>
Seemingly Similar Threads
- Canonical way to handle zero registers?
- Canonical way to handle zero registers?
- Canonical way to handle zero registers?
- Strange regalloc behaviour: one more available register causes much worse allocation
- Strange regalloc behaviour: one more available register causes much worse allocation