Nemanja Ivanovic via llvm-dev
2017-Oct-26 12:54 UTC
[llvm-dev] RFC: Adding bit to register MachineOperands to allow post-RA register renaming
Forgive me if these questions are naive or if I'm misunderstanding something. I'm certainly very interested in seeing the MachineCopyPropagation patch finally land and stick. 1. Wouldn't function live-ins and reserved registers have started life as physical registers already? For example, wouldn't a live-in be a copy from a physical register to a virtual one allowing the flag to be set correctly on the def? A reserved register on the other hand just seems like something we shouldn't touch, doesn't it? 2. I must admit that I don't really know how Aggressive Anti Dependence Breaker works, but doesn't it already rename registers? How does it know which ones are safe to rename and which aren't? On Wed, Oct 25, 2017 at 10:20 PM, Quentin Colombet via llvm-dev < llvm-dev at lists.llvm.org> wrote:> Hi Geoff, > > The principle sounds reasonable but it raises the question of proper APIs > to query that. E.g., when I am looking at a use, how would we know that > this is okay to rename? In other words, what API do we provide for such use > cases. > > Also, what do we do with registers that don’t have definition? For > instance, a function live-ins register, a reserved register, and so on. > > Cheers, > -Quentin > > > On Oct 25, 2017, at 10:27 AM, Geoff Berry <gberry at codeaurora.org> wrote: > > > > Hi All, > > > > Currently, changing register assignments of definitions after register > allocation is not safe because there is no way to know which register > definitions were physical registers before RA (e.g. to meet ABI or ISA > constraints) and thus should not be changed. I'd like to propose adding a > bit to MachineOperand (by overloading the meaning of the IsKill bit for > defs, so no extra storage would be required), that tracks whether a given > register definition was a virtual register before RA. I'll throw out > 'IsRenameable' for a potential name. > > > > Register definitions created with virtual registers would have this bit > set. This bit should be verifiable until after RA. Register definitions > created after RA (presumably with physical registers) would not have this > bit set. I believe the only potential for this bit to be set incorrectly > (and not be caught be verification) would be if a post-RA pass was already > renaming a register definition from a previously virtual register to a > previously non-virtual register, which would arguably be a bug already. > > > > We have encountered several potential uses for this bit. For example, > the MachineCopyPropagation changes I have been working on to forward > register COPYs would likely be greatly simplified if this bit were > available. Other passes, like AArch64LoadStoreOptimizer, which run post-RA > so as not to overly-restrict the register allocator, could be made to catch > more cases if renaming of load instructions could be done safely. > > > > -- > > Geoff Berry > > Employee of Qualcomm Datacenter Technologies, Inc. > > Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm > Technologies, Inc. Qualcomm Technologies, Inc. is a member of the Code > Aurora Forum, a Linux Foundation Collaborative Project. > > _______________________________________________ > 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/20171026/03fed3f5/attachment.html>
Geoff Berry via llvm-dev
2017-Oct-26 17:31 UTC
[llvm-dev] RFC: Adding bit to register MachineOperands to allow post-RA register renaming
Hi All, My thinking is that in cases where you want to do this kind of renaming, you will need to go through the work of finding all the defs that reach a use (or vice-versa), and if you find a def in this case to be a function live-in, then you can't rename that def. Quentin, to answer you question directly, this information would not be available when looking at a use, but only as a way of bailing out once the defs were being analyzed. Nemanja, I'm not that familiar with the details of the AntiDepBreaker pass, but generally speaking, in the case of an anti-dependency, e.g. x0 = INST1 ... x1 = INST2 x0 ... x0 = INST3 you will always know that since x0 is clobbered by INST3, the def of x0 in INST1 and the use of x0 in INST2 can be renamed since that value can't live past INST3. On 10/26/2017 8:54 AM, Nemanja Ivanovic wrote:> Forgive me if these questions are naive or if I'm misunderstanding > something. I'm certainly very interested in seeing the > MachineCopyPropagation patch finally land and stick. > > 1. Wouldn't function live-ins and reserved registers have started life > as physical registers already? For example, wouldn't a live-in be a copy > from a physical register to a virtual one allowing the flag to be set > correctly on the def? A reserved register on the other hand just seems > like something we shouldn't touch, doesn't it > 2. I must admit that I don't really know how Aggressive Anti Dependence > Breaker works, but doesn't it already rename registers? How does it know > which ones are safe to rename and which aren't? > > On Wed, Oct 25, 2017 at 10:20 PM, Quentin Colombet via llvm-dev > <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: > > Hi Geoff, > > The principle sounds reasonable but it raises the question of proper > APIs to query that. E.g., when I am looking at a use, how would we > know that this is okay to rename? In other words, what API do we > provide for such use cases. > > Also, what do we do with registers that don’t have definition? For > instance, a function live-ins register, a reserved register, and so on.> Cheers, > -Quentin > > > On Oct 25, 2017, at 10:27 AM, Geoff Berry <gberry at codeaurora.org > <mailto:gberry at codeaurora.org>> wrote: > > > > Hi All, > > > > Currently, changing register assignments of definitions after > register allocation is not safe because there is no way to know > which register definitions were physical registers before RA (e.g. > to meet ABI or ISA constraints) and thus should not be changed. I'd > like to propose adding a bit to MachineOperand (by overloading the > meaning of the IsKill bit for defs, so no extra storage would be > required), that tracks whether a given register definition was a > virtual register before RA. I'll throw out 'IsRenameable' for a > potential name. > > > > Register definitions created with virtual registers would have > this bit set. This bit should be verifiable until after RA. > Register definitions created after RA (presumably with physical > registers) would not have this bit set. I believe the only > potential for this bit to be set incorrectly (and not be caught be > verification) would be if a post-RA pass was already renaming a > register definition from a previously virtual register to a > previously non-virtual register, which would arguably be a bug already. > > > > We have encountered several potential uses for this bit. For > example, the MachineCopyPropagation changes I have been working on > to forward register COPYs would likely be greatly simplified if this > bit were available. Other passes, like AArch64LoadStoreOptimizer, > which run post-RA so as not to overly-restrict the register > allocator, could be made to catch more cases if renaming of load > instructions could be done safely. > > > > -- > > Geoff Berry > > Employee of Qualcomm Datacenter Technologies, Inc. > > Qualcomm Datacenter Technologies, Inc. as an affiliate of > Qualcomm Technologies, Inc. Qualcomm Technologies, Inc. is a member > of the Code Aurora Forum, a Linux Foundation Collaborative Project. > > _______________________________________________ > 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> > >-- Geoff Berry Employee of Qualcomm Datacenter Technologies, Inc. Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm Technologies, Inc. Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project.
Matthias Braun via llvm-dev
2017-Oct-26 17:52 UTC
[llvm-dev] RFC: Adding bit to register MachineOperands to allow post-RA register renaming
I like the idea, this is not the first time we try to perform recoloring/renaming operations late. I agree with Quentin though that we should have a way to mark def and use operands! You can probably play more games and re-use the IsDead bit on use operands.> On Oct 26, 2017, at 5:54 AM, Nemanja Ivanovic via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Forgive me if these questions are naive or if I'm misunderstanding something. I'm certainly very interested in seeing the MachineCopyPropagation patch finally land and stick. > > 1. Wouldn't function live-ins and reserved registers have started life as physical registers already? For example, wouldn't a live-in be a copy from a physical register to a virtual one allowing the flag to be set correctly on the def? A reserved register on the other hand just seems like something we shouldn't touch, doesn't it? > 2. I must admit that I don't really know how Aggressive Anti Dependence Breaker works, but doesn't it already rename registers? How does it know which ones are safe to rename and which aren't?Heuristics which seem to work today but which at least I am not very comfortable with. I think it's mostly this part: // If MI's defs have a special allocation requirement, don't allow // any def registers to be changed. Also assume all registers // defined in a call must not be changed (ABI). Inline assembly may // reference either system calls or the register directly. Skip it until we // can tell user specified registers from compiler-specified. if (MI.isCall() || MI.hasExtraDefRegAllocReq() || TII->isPredicated(MI) || MI.isInlineAsm()) { DEBUG(if (State->GetGroup(Reg) != 0) dbgs() << "->g0(alloc-req)"); State->UnionGroups(Reg, 0); } - Matthias> > On Wed, Oct 25, 2017 at 10:20 PM, Quentin Colombet via llvm-dev <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: > Hi Geoff, > > The principle sounds reasonable but it raises the question of proper APIs to query that. E.g., when I am looking at a use, how would we know that this is okay to rename? In other words, what API do we provide for such use cases. > > Also, what do we do with registers that don’t have definition? For instance, a function live-ins register, a reserved register, and so on. > > Cheers, > -Quentin > > > On Oct 25, 2017, at 10:27 AM, Geoff Berry <gberry at codeaurora.org <mailto:gberry at codeaurora.org>> wrote: > > > > Hi All, > > > > Currently, changing register assignments of definitions after register allocation is not safe because there is no way to know which register definitions were physical registers before RA (e.g. to meet ABI or ISA constraints) and thus should not be changed. I'd like to propose adding a bit to MachineOperand (by overloading the meaning of the IsKill bit for defs, so no extra storage would be required), that tracks whether a given register definition was a virtual register before RA. I'll throw out 'IsRenameable' for a potential name. > > > > Register definitions created with virtual registers would have this bit set. This bit should be verifiable until after RA. Register definitions created after RA (presumably with physical registers) would not have this bit set. I believe the only potential for this bit to be set incorrectly (and not be caught be verification) would be if a post-RA pass was already renaming a register definition from a previously virtual register to a previously non-virtual register, which would arguably be a bug already. > > > > We have encountered several potential uses for this bit. For example, the MachineCopyPropagation changes I have been working on to forward register COPYs would likely be greatly simplified if this bit were available. Other passes, like AArch64LoadStoreOptimizer, which run post-RA so as not to overly-restrict the register allocator, could be made to catch more cases if renaming of load instructions could be done safely. > > > > -- > > Geoff Berry > > Employee of Qualcomm Datacenter Technologies, Inc. > > Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm Technologies, Inc. Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project. > > _______________________________________________ > 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> > > _______________________________________________ > 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/20171026/e7c8a809/attachment.html>
Hal Finkel via llvm-dev
2017-Oct-26 18:47 UTC
[llvm-dev] RFC: Adding bit to register MachineOperands to allow post-RA register renaming
On 10/26/2017 12:52 PM, Matthias Braun via llvm-dev wrote:> I like the idea, this is not the first time we try to perform > recoloring/renaming operations late. I agree with Quentin though that > we should have a way to mark def and use operands! You can probably > play more games and re-use the IsDead bit on use operands. > >> On Oct 26, 2017, at 5:54 AM, Nemanja Ivanovic via llvm-dev >> <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: >> >> Forgive me if these questions are naive or if I'm misunderstanding >> something. I'm certainly very interested in seeing the >> MachineCopyPropagation patch finally land and stick. >> >> 1. Wouldn't function live-ins and reserved registers have started >> life as physical registers already? For example, wouldn't a live-in >> be a copy from a physical register to a virtual one allowing the flag >> to be set correctly on the def? A reserved register on the other hand >> just seems like something we shouldn't touch, doesn't it? >> 2. I must admit that I don't really know how Aggressive Anti >> Dependence Breaker works, but doesn't it already rename registers? >> How does it know which ones are safe to rename and which aren't? > Heuristics which seem to work today but which at least I am not very > comfortable with.+1 It would be nice to replace this with a less fragile approach. We already have number of instructions marked with hasExtraSrcRegAllocReq and/or hasExtraDefRegAllocReq, and this seems like a more-precise, dynamic, version of that. I don't recall this being mentioned, but I imagine we'll also, in many cases, want to mark registers returned by the scavenger marked as eligible for renaming. -Hal> I think it's mostly this part: > > // If MI's defs have a special allocation requirement, don't allow > // any def registers to be changed. Also assume all registers > // defined in a call must not be changed (ABI). Inline assembly may > // reference either system calls or the register directly. Skip it > until we > // can tell user specified registers from compiler-specified. > if (MI.isCall() || MI.hasExtraDefRegAllocReq() || > TII->isPredicated(MI) || > MI.isInlineAsm()) { > DEBUG(if (State->GetGroup(Reg) != 0) dbgs() << "->g0(alloc-req)"); > State->UnionGroups(Reg, 0); > } > > - Matthias > >> >> On Wed, Oct 25, 2017 at 10:20 PM, Quentin Colombet via llvm-dev >> <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: >> >> Hi Geoff, >> >> The principle sounds reasonable but it raises the question of >> proper APIs to query that. E.g., when I am looking at a use, how >> would we know that this is okay to rename? In other words, what >> API do we provide for such use cases. >> >> Also, what do we do with registers that don’t have definition? >> For instance, a function live-ins register, a reserved register, >> and so on. >> >> Cheers, >> -Quentin >> >> > On Oct 25, 2017, at 10:27 AM, Geoff Berry >> <gberry at codeaurora.org <mailto:gberry at codeaurora.org>> wrote: >> > >> > Hi All, >> > >> > Currently, changing register assignments of definitions after >> register allocation is not safe because there is no way to know >> which register definitions were physical registers before RA >> (e.g. to meet ABI or ISA constraints) and thus should not be >> changed. I'd like to propose adding a bit to MachineOperand (by >> overloading the meaning of the IsKill bit for defs, so no extra >> storage would be required), that tracks whether a given register >> definition was a virtual register before RA. I'll throw out >> 'IsRenameable' for a potential name. >> > >> > Register definitions created with virtual registers would have >> this bit set. This bit should be verifiable until after RA. >> Register definitions created after RA (presumably with physical >> registers) would not have this bit set. I believe the only >> potential for this bit to be set incorrectly (and not be caught >> be verification) would be if a post-RA pass was already renaming >> a register definition from a previously virtual register to a >> previously non-virtual register, which would arguably be a bug >> already. >> > >> > We have encountered several potential uses for this bit. For >> example, the MachineCopyPropagation changes I have been working >> on to forward register COPYs would likely be greatly simplified >> if this bit were available. Other passes, like >> AArch64LoadStoreOptimizer, which run post-RA so as not to >> overly-restrict the register allocator, could be made to catch >> more cases if renaming of load instructions could be done safely. >> > >> > -- >> > Geoff Berry >> > Employee of Qualcomm Datacenter Technologies, Inc. >> > Qualcomm Datacenter Technologies, Inc. as an affiliate of >> Qualcomm Technologies, Inc. Qualcomm Technologies, Inc. is a >> member of the Code Aurora Forum, a Linux Foundation Collaborative >> Project. >> >> _______________________________________________ >> 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> >> >> >> _______________________________________________ >> 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 > > > > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev-- Hal Finkel Lead, Compiler Technology and Programming Languages Leadership Computing Facility Argonne National Laboratory -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20171026/3d72f54e/attachment.html>