search for: regscavenger

...e second operand have a <kill> flag? a: %R0<def> = MUL %R0, %R1<kill> b: %R0<def> = MUL %R0<kill>, %R1<kill> I think the current policy is a: There should be no kill-flag. The machine code verifier has code to handle the missing <kill> flag, and the regscavenger asserts if the <kill> flag is set. Recently somebody (possibly myself) has been setting <kill> flags on my tied use operands, causing regscavenger to assert. I just want to verify the policy regarding two-address <kill> flags: Case a: <kill> is not allowed. I should add...

On Mar 25, 2013, at 12:04 PM, Akira Hatanaka <ahatanak at gmail.com> wrote: > This patch adds parameter "EliminateFI" to RegScavenger::scavengeRegister, which tells register scavenger not to eliminate frame index of the emergency spill slot if set to false. > > I have pseudo load, store and copy instructions which are generated during register allocation and expanded post-RA but before the final stack size is known. I use...

This patch adds parameter "EliminateFI" to RegScavenger::scavengeRegister, which tells register scavenger not to eliminate frame index of the emergency spill slot if set to false. I have pseudo load, store and copy instructions which are generated during register allocation and expanded post-RA but before the final stack size is known. I use register s...

...flag? > > a: %R0<def> = MUL %R0, %R1<kill> > b: %R0<def> = MUL %R0<kill>, %R1<kill> > > I think the current policy is a: There should be no kill-flag. The Right. > machine code verifier has code to handle the missing <kill> flag, and > the regscavenger asserts if the <kill> flag is set. > > Recently somebody (possibly myself) has been setting <kill> flags on > my tied use operands, causing regscavenger to assert. > > I just want to verify the policy regarding two-address <kill> flags: > > Case a: <kill&gt...

...forward() in any form if there are virtual registers being used by any of the instructions in the basic block. This will cause forward to fail. Maybe this is a bug in forward() On 02/05/2013 02:51 PM, Reed Kotler wrote: > Does not seem that anyone is using the more advanced features of > RegScavenger > > On 02/05/2013 01:09 PM, reed kotler wrote: >> I ran into a case in Mips16 where I need two registers. >> >> The problem arises from the fact that SP is not a mips16 register. >> You can implicitly use it in load/store and, move it to/from a mips16 >> register...

...t; >> 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...

...ere are a bunch of mips32 registers that are hard to use in mips16 so at this time, I only use them in special situations. So they are convenient for temporarily storing mips16 registers. mips16 registers is a subset of the full mips32 register set. so i'm guessing that I can still use the RegScavenger class for this. I'm thinking of something [not sure if this is a correct understanding of this API] RegScavenger rs; rs.enterBasicBlock(MBB); forward(II); and then I can get and set available registers???? Ideally I could use usual way to get the first register I need by implementing the...

...t;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-bi...

...lund 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...

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

...owed to do that. I am mostly working on x86 and TII.storeRegToStackSlot for x86 doesn't create new register. As you said, if TII.storeRegToStackSlot is allowed to create new virtual registers, that could be a problem. It is not exposed maybe because of some later pass cover the problem -- maybe RegScavenger? Are you aware of any other architecture other than AMDGPU on which TII.storeRegToStackSlot creates new virtual registers? Could you explain in which case new virtual registers will be created? Thanks, Wei. > > > > As a side note, compiler option "-disable-spill-hoist" (Di...

...lund 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 gma...

...are virtual registers being used by any of the instructions in the basic block. This will cause forward to fail. > > Maybe this is a bug in forward() > > > On 02/05/2013 02:51 PM, Reed Kotler wrote: >> Does not seem that anyone is using the more advanced features of >> RegScavenger >> >> On 02/05/2013 01:09 PM, reed kotler wrote: >>> I ran into a case in Mips16 where I need two registers. >>> >>> The problem arises from the fact that SP is not a mips16 register. >>> You can implicitly use it in load/store and, move it to/from...

Does not seem that anyone is using the more advanced features of RegScavenger On 02/05/2013 01:09 PM, reed kotler wrote: > I ran into a case in Mips16 where I need two registers. > > The problem arises from the fact that SP is not a mips16 register. > You can implicitly use it in load/store and, move it to/from a mips16 > register and add small immediate valu...

Hello all, For my custom processor backend I am trying add some instruction using BuildMI() inside eliminateFrameIndex(). I tried RegScavenger like this: unsigned RegUnused0 = RS->FindUnusedReg(&LASER::GNPRegsRegClass); if (!RegUnused0) RegUnused0 = RS->scavengeRegister(&LASER::GNPRegsRegClass, II, SPAdj); assert(RegUnused0 && "Register scavenger failed"); RS->setRegUsed(RegUnused0); It works but the...

On Mar 25, 2013, at 2:51 PM, Akira Hatanaka <ahatanak at gmail.com> wrote: > Yes, it sounds like it will solve the problem. > > Using the following example where live ranges of accumulators $vreg_acc0 and $vreg_acc1 conflict, > > MULT $vreg_acc0, $vreg_gpr0, $vreg_gpr1 > MULT $vreg_acc1, $vreg_gpr2, $vreg_gpr3 > > (consumer of $vreg_acc1) > (consumer of

On Mon, Mar 25, 2013 at 4:02 PM, Jakob Stoklund Olesen <stoklund at 2pi.dk>wrote: > > On Mar 25, 2013, at 2:51 PM, Akira Hatanaka <ahatanak at gmail.com> wrote: > > > Yes, it sounds like it will solve the problem. > > > > Using the following example where live ranges of accumulators $vreg_acc0 > and $vreg_acc1 conflict, > > > > MULT

...difficult problem to solve. Is that right? On Mon, Mar 25, 2013 at 1:06 PM, Jakob Stoklund Olesen <stoklund at 2pi.dk>wrote: > > On Mar 25, 2013, at 12:04 PM, Akira Hatanaka <ahatanak at gmail.com> wrote: > > > This patch adds parameter "EliminateFI" to > RegScavenger::scavengeRegister, which tells register scavenger not to > eliminate frame index of the emergency spill slot if set to false. > > > > I have pseudo load, store and copy instructions which are generated > during register allocation and expanded post-RA but before the final stack &g...

On Mar 25, 2013, at 1:41 PM, Akira Hatanaka <ahatanak at gmail.com> wrote: > Hi Jakob, > > I believe Hal is trying to enable register scavenger to find two (or more) registers that can be used as temporaries. > > One problem I see with this approach is that, if you use register scavenger during PEI, you will have to pessimistically set aside two emergency spill slots before

On Mon, Mar 25, 2013 at 2:07 PM, Jakob Stoklund Olesen <stoklund at 2pi.dk>wrote: > > On Mar 25, 2013, at 1:41 PM, Akira Hatanaka <ahatanak at gmail.com> wrote: > > > Hi Jakob, > > > > I believe Hal is trying to enable register scavenger to find two (or > more) registers that can be used as temporaries. > > > > One problem I see with this