Re: [m68k]: More trouble with byte moves into Address registers

[Ian Lance Taylor <ian at airs dot com>]

Peter Barada <peter@the-baradas.com> 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