This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Unable to reload subreg


René Willemink wrote:
This should perform a double word addition (HImode on my target). Since I haven't defined an addhi3 instruction, gcc tries to solve this problem with addqi3, and uses (subreg:QI (reg:HI)) to access the low and high part of this double word value. The problem I run into is that in my cross compiler seems not to be able to reload the destination (subreg:QI (reg:HI)) into a QImode register. This happens when I adjust the constraints to force the result into a register. When I allow the result in memory, no error occurs.

There isn't enough info here to identify the problem, though I can make some educated guesses.


Try adding the -da option, and looking at the .greg output file. This will include info about the reloads generated for the insn in question, and may give clues as to why reload was not able to allocate registers for all of the reloads.

The problem here could be that you don't have enough registers. A 3-operand HImode add needs worst case 6 QImode registers. If every operand if a pseudo, then you may need 3 QImode reload registers. Generally, reload will not function unless there are at least 3 registers available to it. That gives us 9 registers worst case. In practice, I think 7 registers at most would be needed. If you have 8 registers, and one if reserved for the stack pointer and one for the frame pointer then you are out of luck. If you modify the pattern to use a matching constraint, which effecively turns it into a 2-operand add, then I think you can get by with 5 registers. This may be enough to make it work.

Modifying the pattern to use MEM operands instead of register operands will help, and may even result in better code, because of less register pressure.

Some 8-bit parts define a page in memory to hold registers, e.g. if you have instructions that can quickly load from zero-page memory, then you can define some "registers" in zero-page memory, and emit load/store instructions to access them. This may make register allocation/reload work better, by providing enough registers for them to function well. You can discourage use of the in-memory registers by making them more expensive.
--
Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]