>> Would it help to rearrange the constraints to have reg +=
>> mem|reg|constant before the addreg += ... ?
>
>Probably not in this case. You could try it. It is true that when
>two alternatives have the same cost, reload will pick the first one
>listed.
With my luck that will cause a bigger problem somewhere else. :) I'll
try it once I get past this.
>> >I don't know where else register 1421 is being used, so my tentative
>> >guess would be that gcc is picking an address register based on the
>> >constraints in addsi3_5200. Perhaps you need to change "?a" to "*a".
>> >After all, you probably don't want to encourage pseudos to go into the
>> >address registers merely because you add values to them.
>>
>> 1421 is only used in 5559 and 5560. from the lreg dump:
>>
>> Register 1421 used 2 times across 2 insns in block 694; set 1 time; pref
>> DATA_REGS.
>
>That is odd. Your earlier e-mail seemed to show that register 1421
>was specifically put into an address register, specifically %a0. Why
>would that happen if it has a preference for DATA_REGS? Was it
>assigned by local-alloc? In that case you would see a line like ";;
>Register 2421 in NNN." in the .lreg dump file.
Uggh. I've been trying changes currently so I don't have the original
compiler to regenerate the output.
>> 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?
>> 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().
That is assuming that changing PREFERRED_RELOAD_CLASS this way doesn't
severely break reload.
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 :)
I'll undo the change to PREFERRED_RELOAD_CLASS, and then change the
'?a' to '*a' in addsi3_5200 to see if that helps reload to not pick
and ADDR_REG for the value. If it still fails, I'll regenerate all
the information as I did in the 2nd email to you.
Thanks!
--
Peter Barada
[EMAIL PROTECTED]
