----- Original Message -----> From: "Jakob Stoklund Olesen" <stoklund at 2pi.dk> > To: "Akira Hatanaka" <ahatanak at gmail.com> > Cc: "LLVM Developers Mailing List" <llvmdev at cs.uiuc.edu>, "Hal Finkel" <hfinkel at anl.gov> > Sent: Tuesday, March 26, 2013 12:40:44 PM > Subject: Re: [LLVMdev] [PATCH] RegScavenger::scavengeRegister > > > On Mar 26, 2013, at 10:29 AM, Akira Hatanaka <ahatanak at gmail.com> > wrote: > > > The size of general purpose integer registers for mips32 is 32-bit > > and accumulators are 64-bit registers consisting of 32-bit hi/lo > > register pairs. So you will need two instructions to copy two > > 32-bit GPR registers to a 64-bit accumulator register. If spilling > > to multiple registers is unsupported, perhaps I can I define a new > > register class consisting of paired GPR registers and pseudo copy > > instructions? > > Yes, that would work. Look at the ARM GPRPair register class.In the PPC case, for CR spilling, the CRs are only really 4 bits; I'd need to define 8-tuples just to pair with 32-bit GPR registers. Under normal circumstances, i32 is the smallest legal type. Instead, to make this work, would I define a 4-bit subregister of the GPRs to hold the data (or maybe 8 bits, and then also use some CR-pair register class)? Thanks again, Hal> > You don't need pseudo copy instructions, TII::copyPhysReg() is > allowed to insert multiple instructions. > > > > Also, should RA avoid splitting live intervals of accumulators, > > > which creates copy instructions? > > > > The alternative to live range splitting is spilling, which is > > usually worse. > > > > Here I was assuming register allocator will spill accumulator > > registers to integer registers instead of directly to stack. In > > that case, splitting might be worse than spilling since reload > > requires two GPR-to-accumulator copy instructions while copying > > one accumulator to another requires four copy instructions > > (instruction set doesn't have any accumulator-to-accumulator copy > > instructions): > > > > copy $vreg_gpr0, $vreg_acc0:lo > > copy $vreg_gpr1, $vreg_acc0:hi > > copy $vreg_acc1:lo, $vreg_gpr0 > > copy $vreg_acc1:hi, $vreg_gpr1 > > There is no way of preventing copies completely. > > Once you create a virtual register with some register class, you must > support spilling, reloading, and copying of that register class. > > The cross class spilling feature can make these things less frequent, > but it can't make them go away completely. > > /jakob > >
Jakob Stoklund Olesen
2013-Apr-06 16:56 UTC
[LLVMdev] [PATCH] RegScavenger::scavengeRegister
On Apr 6, 2013, at 12:42 AM, Hal Finkel <hfinkel at anl.gov> wrote:> ----- Original Message ----- >> From: "Jakob Stoklund Olesen" <stoklund at 2pi.dk> >> To: "Akira Hatanaka" <ahatanak at gmail.com> >> Cc: "LLVM Developers Mailing List" <llvmdev at cs.uiuc.edu>, "Hal Finkel" <hfinkel at anl.gov> >> Sent: Tuesday, March 26, 2013 12:40:44 PM >> Subject: Re: [LLVMdev] [PATCH] RegScavenger::scavengeRegister >> >> >> On Mar 26, 2013, at 10:29 AM, Akira Hatanaka <ahatanak at gmail.com> >> wrote: >> >>> The size of general purpose integer registers for mips32 is 32-bit >>> and accumulators are 64-bit registers consisting of 32-bit hi/lo >>> register pairs. So you will need two instructions to copy two >>> 32-bit GPR registers to a 64-bit accumulator register. If spilling >>> to multiple registers is unsupported, perhaps I can I define a new >>> register class consisting of paired GPR registers and pseudo copy >>> instructions? >> >> Yes, that would work. Look at the ARM GPRPair register class. > > In the PPC case, for CR spilling, the CRs are only really 4 bits; I'd need to define 8-tuples just to pair with 32-bit GPR registers. Under normal circumstances, i32 is the smallest legal type. Instead, to make this work, would I define a 4-bit subregister of the GPRs to hold the data (or maybe 8 bits, and then also use some CR-pair register class)?No, that shouldn't be necessary. The types on register classes are only used by isel, and this register class wouldn't be used before register allocation. Just make it [i32], or even [untyped]. (The type is used to pick a default spill size, so you may need to 'let Size = 4' if you go with untyped). Your implementation in copyPhysReg is the final word on what it means to copy between registers in this class. The register class will not be used automatically without permission from your implementation of getLargestLegalSuperClass. This function should not allow normal GPR registers to be inflated to the GPR+CR super-class because not all registers in that class have enough bits. X86RegisterInfo::getLargestLegalSuperClass() does something similar with the GR8_NOREX register class to work around some awkward x86 encoding issues with the 20 8-bit registers. /jakob
----- Original Message -----> From: "Jakob Stoklund Olesen" <stoklund at 2pi.dk> > To: "Hal Finkel" <hfinkel at anl.gov> > Cc: "LLVM Developers Mailing List" <llvmdev at cs.uiuc.edu>, "Akira Hatanaka" <ahatanak at gmail.com> > Sent: Saturday, April 6, 2013 11:56:28 AM > Subject: Re: [LLVMdev] [PATCH] RegScavenger::scavengeRegister > > > On Apr 6, 2013, at 12:42 AM, Hal Finkel <hfinkel at anl.gov> wrote: > > > ----- Original Message ----- > >> From: "Jakob Stoklund Olesen" <stoklund at 2pi.dk> > >> To: "Akira Hatanaka" <ahatanak at gmail.com> > >> Cc: "LLVM Developers Mailing List" <llvmdev at cs.uiuc.edu>, "Hal > >> Finkel" <hfinkel at anl.gov> > >> Sent: Tuesday, March 26, 2013 12:40:44 PM > >> Subject: Re: [LLVMdev] [PATCH] RegScavenger::scavengeRegister > >> > >> > >> On Mar 26, 2013, at 10:29 AM, Akira Hatanaka <ahatanak at gmail.com> > >> wrote: > >> > >>> The size of general purpose integer registers for mips32 is > >>> 32-bit > >>> and accumulators are 64-bit registers consisting of 32-bit hi/lo > >>> register pairs. So you will need two instructions to copy two > >>> 32-bit GPR registers to a 64-bit accumulator register. If > >>> spilling > >>> to multiple registers is unsupported, perhaps I can I define a > >>> new > >>> register class consisting of paired GPR registers and pseudo copy > >>> instructions? > >> > >> Yes, that would work. Look at the ARM GPRPair register class. > > > > In the PPC case, for CR spilling, the CRs are only really 4 bits; > > I'd need to define 8-tuples just to pair with 32-bit GPR > > registers. Under normal circumstances, i32 is the smallest legal > > type. Instead, to make this work, would I define a 4-bit > > subregister of the GPRs to hold the data (or maybe 8 bits, and > > then also use some CR-pair register class)? > > No, that shouldn't be necessary. > > The types on register classes are only used by isel, and this > register class wouldn't be used before register allocation. Just > make it [i32], or even [untyped]. (The type is used to pick a > default spill size, so you may need to 'let Size = 4' if you go with > untyped). > > Your implementation in copyPhysReg is the final word on what it means > to copy between registers in this class. > > The register class will not be used automatically without permission > from your implementation of getLargestLegalSuperClass. This function > should not allow normal GPR registers to be inflated to the GPR+CR > super-class because not all registers in that class have enough > bits. > > X86RegisterInfo::getLargestLegalSuperClass() does something similar > with the GR8_NOREX register class to work around some awkward x86 > encoding issues with the 20 8-bit registers.Okay, thanks! So when the RA decides to use this register inflation mechanism, it decides on both the inflation point and the deflation point at the same time? I'd like to understand this better, can you please provide a pointer to the logic for this? -Hal> > /jakob > >
Is there a way to force or increase the likelihood of rematerialization of condition registers, instead of copying or spilling? mips isa doesn't have a handy instruction which enables reading or writing condition registers in one or two cycles (you need several shift and masking operations), so it makes more sense to rematerialize, if that's possible. On Sat, Apr 6, 2013 at 9:56 AM, Jakob Stoklund Olesen <stoklund at 2pi.dk>wrote:> > On Apr 6, 2013, at 12:42 AM, Hal Finkel <hfinkel at anl.gov> wrote: > > > ----- Original Message ----- > >> From: "Jakob Stoklund Olesen" <stoklund at 2pi.dk> > >> To: "Akira Hatanaka" <ahatanak at gmail.com> > >> Cc: "LLVM Developers Mailing List" <llvmdev at cs.uiuc.edu>, "Hal Finkel" > <hfinkel at anl.gov> > >> Sent: Tuesday, March 26, 2013 12:40:44 PM > >> Subject: Re: [LLVMdev] [PATCH] RegScavenger::scavengeRegister > >> > >> > >> On Mar 26, 2013, at 10:29 AM, Akira Hatanaka <ahatanak at gmail.com> > >> wrote: > >> > >>> The size of general purpose integer registers for mips32 is 32-bit > >>> and accumulators are 64-bit registers consisting of 32-bit hi/lo > >>> register pairs. So you will need two instructions to copy two > >>> 32-bit GPR registers to a 64-bit accumulator register. If spilling > >>> to multiple registers is unsupported, perhaps I can I define a new > >>> register class consisting of paired GPR registers and pseudo copy > >>> instructions? > >> > >> Yes, that would work. Look at the ARM GPRPair register class. > > > > In the PPC case, for CR spilling, the CRs are only really 4 bits; I'd > need to define 8-tuples just to pair with 32-bit GPR registers. Under > normal circumstances, i32 is the smallest legal type. Instead, to make this > work, would I define a 4-bit subregister of the GPRs to hold the data (or > maybe 8 bits, and then also use some CR-pair register class)? > > No, that shouldn't be necessary. > > The types on register classes are only used by isel, and this register > class wouldn't be used before register allocation. Just make it [i32], or > even [untyped]. (The type is used to pick a default spill size, so you may > need to 'let Size = 4' if you go with untyped). > > Your implementation in copyPhysReg is the final word on what it means to > copy between registers in this class. > > The register class will not be used automatically without permission from > your implementation of getLargestLegalSuperClass. This function should not > allow normal GPR registers to be inflated to the GPR+CR super-class because > not all registers in that class have enough bits. > > X86RegisterInfo::getLargestLegalSuperClass() does something similar with > the GR8_NOREX register class to work around some awkward x86 encoding > issues with the 20 8-bit registers. > > /jakob > >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130409/b009d3b9/attachment.html>