reed kotler
2015-Jan-03 03:32 UTC
[LLVMdev] "ran out of registers during register allocation"
It seems like it might be a legitimate complaint from the register allocator. It's trying to get an accumulator (not a general purpose register) and the accumulator is 64 bit. It's using a part of the Mips backend that I have not worked in so I have to research this a bit. The multiply instruction is a pseudo multiply in the mips backend and it needs the accumulator which a special register and there is only one and it has special properties. This may normally be getting sorted out by some code which is not present during fast-isel. On 01/02/2015 02:41 PM, Philip Reames wrote:> > On 01/02/2015 02:24 PM, reed kotler wrote: >> I'm getting this error in RegAllocFast.cpp in compiling one source >> file in test-suite as the result of a new Mips fast-isel patch >> I was testing. >> >> It apparently just generates bad code and continues? >> >> // Nothing we can do. Report an error and keep going with a bad >> allocation. >> if (MI->isInlineAsm()) >> MI->emitError("inline assembly requires more registers than >> available"); >> else >> MI->emitError("ran out of registers during register allocation"); >> >> >> How is it possible to run out of registers during register >> allocation? Lol. > This seems to be one of the more common errors when you get a MI > instruction definition wrong. In particular, I saw this a lot when > experimenting with various lowering strategies for the statepoint > work. I'd suggest trying to reduce the example using bugpoint and > looking closely at the machine instructions. >> >> Reed >> _______________________________________________ >> LLVM Developers mailing list >> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >
Reed Kotler
2015-Jan-03 04:56 UTC
[LLVMdev] "ran out of registers during register allocation"
It should not be able to do any 64 bit integer arithmetic in mips fast-isel that is probably the issue; which is the only reason i think that it would need the multu or mult instructions. On 01/02/2015 07:32 PM, reed kotler wrote:> It seems like it might be a legitimate complaint from the register > allocator. > > It's trying to get an accumulator (not a general purpose register) and > the accumulator is 64 bit. > > It's using a part of the Mips backend that I have not worked in so I > have to research this a bit. > > The multiply instruction is a pseudo multiply in the mips backend and it > needs the accumulator which a special register > and there is only one and it has special properties. This may normally > be getting sorted out by some code which > is not present during fast-isel. > > > > On 01/02/2015 02:41 PM, Philip Reames wrote: >> >> On 01/02/2015 02:24 PM, reed kotler wrote: >>> I'm getting this error in RegAllocFast.cpp in compiling one source >>> file in test-suite as the result of a new Mips fast-isel patch >>> I was testing. >>> >>> It apparently just generates bad code and continues? >>> >>> // Nothing we can do. Report an error and keep going with a bad >>> allocation. >>> if (MI->isInlineAsm()) >>> MI->emitError("inline assembly requires more registers than >>> available"); >>> else >>> MI->emitError("ran out of registers during register allocation"); >>> >>> >>> How is it possible to run out of registers during register >>> allocation? Lol. >> This seems to be one of the more common errors when you get a MI >> instruction definition wrong. In particular, I saw this a lot when >> experimenting with various lowering strategies for the statepoint >> work. I'd suggest trying to reduce the example using bugpoint and >> looking closely at the machine instructions. >>> >>> Reed >>> _______________________________________________ >>> LLVM Developers mailing list >>> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >>
Daniel Sanders
2015-Jan-06 16:27 UTC
[LLVMdev] "ran out of registers during register allocation"
Hi Reed, When I trigger this error it's often because I have a virtual register that has contradictory allocation requirements. The register allocator ends up with zero registers to choose from and emits the 'ran out of registers' message. In this case I'd hazard a guess that you have a virtual register that is def'd as an ACC64 and used as a GPR32. ________________________________________ From: llvmdev-bounces at cs.uiuc.edu [llvmdev-bounces at cs.uiuc.edu] on behalf of Reed Kotler Sent: 03 January 2015 04:56 To: Philip Reames; LLVMdev at cs.uiuc.edu Subject: Re: [LLVMdev] "ran out of registers during register allocation" It should not be able to do any 64 bit integer arithmetic in mips fast-isel that is probably the issue; which is the only reason i think that it would need the multu or mult instructions. On 01/02/2015 07:32 PM, reed kotler wrote:> It seems like it might be a legitimate complaint from the register > allocator. > > It's trying to get an accumulator (not a general purpose register) and > the accumulator is 64 bit. > > It's using a part of the Mips backend that I have not worked in so I > have to research this a bit. > > The multiply instruction is a pseudo multiply in the mips backend and it > needs the accumulator which a special register > and there is only one and it has special properties. This may normally > be getting sorted out by some code which > is not present during fast-isel. > > > > On 01/02/2015 02:41 PM, Philip Reames wrote: >> >> On 01/02/2015 02:24 PM, reed kotler wrote: >>> I'm getting this error in RegAllocFast.cpp in compiling one source >>> file in test-suite as the result of a new Mips fast-isel patch >>> I was testing. >>> >>> It apparently just generates bad code and continues? >>> >>> // Nothing we can do. Report an error and keep going with a bad >>> allocation. >>> if (MI->isInlineAsm()) >>> MI->emitError("inline assembly requires more registers than >>> available"); >>> else >>> MI->emitError("ran out of registers during register allocation"); >>> >>> >>> How is it possible to run out of registers during register >>> allocation? Lol. >> This seems to be one of the more common errors when you get a MI >> instruction definition wrong. In particular, I saw this a lot when >> experimenting with various lowering strategies for the statepoint >> work. I'd suggest trying to reduce the example using bugpoint and >> looking closely at the machine instructions. >>> >>> Reed >>> _______________________________________________ >>> LLVM Developers mailing list >>> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >>_______________________________________________ LLVM Developers mailing list LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev