This is the mail archive of the 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: [m68k]: More trouble with byte moves into Address registers

>> 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

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

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))
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

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.


Peter Barada

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