Peter Barada <[EMAIL PROTECTED]> writes:
> >> The problem is that there is no valid QImode instruction that can move
> >> values in/out of an address register....
> >
> >I know. I'm suggesting that QImode values have to move in and out of
> >address registers via data registers, so you just put the QImode value
> >into the data register, and then move it into the address register, or
> >vice-versa.
>
> Is there another backend in GCC I can look at for examples of how this
> is done?
Well, the i386, for example, does it for QImode spills from anything
other than the basic four registers. Look at
SECONDARY_OUTPUT_RELOAD_CLASS and reload_outqi.
> >> Which looks like it allows QImode into ADDR_REGS instead
> >> of insisting on DATA_REGS. Do you think this should be:
> >
> >No, that will break reload. If it calls PREFERRED_RELOAD_CLASS with
> >ADDR_REGS, then it has already selected an alternative which requires
> >ADDR_REGS. Returning a register class which does not permit any
> >register in ADDR_REGS will give you a constraint violation later on.
>
> Well I tried it anyway and was able to build a complete C
> toolchain(including glibc-2.3.2), but it blew up at the same point
> building perl with a constraint violation of:
>
> pp_pack.c: In function `S_unpack_rec':
> pp_pack.c:2220: error: insn does not satisfy its constraints:
> (insn 5559 8594 8595 694 pp_pack.c:2144 (set (reg:SI 8 %a0 [1421])
> (plus:SI (reg:SI 0 %d0)
> (const_int -32 [0xffffffe0]))) 121 {*addsi3_5200} (insn_list 5558
> (nil))
> (nil))
> pp_pack.c:2220: internal compiler error: in reload_cse_simplify_operands, at
> postreload.c:391
>
> This would be easy to fix by adding "?r/r/mi" to addsi3_5200 and
> emit code that first 'move.l %1,%0', and then add the string from
> output_addsi3().
If you add that alternative, then you don't need to change
PREFERRED_RELOAD_CLASS anyhow.
> That is assuming that changing PREFERRED_RELOAD_CLASS this way doesn't
> severely break reload.
It will. Don't do it. Once reload has decided that it needs
ADDR_REGS, you can't use PREFERRED_RELOAD_CLASS to back out of that
decision.
> Where in reload would you think it decides that it absolutely has to
> have an ADDR_REG for 1421? I'll dig into it with gdb, but there's so
> much code in reload that a clue or two would *really* help :)
Basically, it's because reload decided that the best matching
alternative was the one which used address regs for both registers.
This presumably happened in find_reloads.
Ian
