Re: cross gcc port problem

["Oleg I. Vdovikin" <vdovikin at jscc dot ru>]

Hello,
    Alan & Hans-Peter!

> >generally the port register description can cause this.  (Let's
> >not assume it's a core gcc bug for the moment. ;-)
>
> The first problem is most likely patterns that in their worst case will
require
> three memory references, and you only have two available scratch index
registers.

    I'm back with first problem. Today I've figure out the problem, but did
not a solution for it. The problems arises from the fact what this processor
can't move the contents of index register to the arbitrary memory locations,
so when gcc wants to move this register to the memory it needs
secondary_reload, with accumulator as the scratch register. So, I've defined
SECONDARY_RELOAD_CLASS macro as follows -

#define SECONDARY_RELOAD_CLASS(CLASS,MODE,X) \
    (class == BASE_REGS && GET_CODE(x) == MEM) ? BASE_REGS : NO_REGS;
    Also, I've defined reload_inX & reload_outX teplates in the md file.

    Unfortunatly when I'm trying to use gcc in this way I've got "Unable to
find a register to spill"...
    But when I've defined SECONDARY_RELOAD_CLASS as NO_REGS and add "m"
alternatives to the movqi templates, port will compile everything just fine,
but produces instructions which is not available on this processor. It's
possible to define sequence of instructions which will save accumulator
temporary, then performs move, and restores accumulator, but we've 2
disadvantages here - the first one is the unknown size of operand in the
accumulator (may be int, long, float) & the later is the emision of the
temporary saves/restores when the accumulator value does not realy matter.

    So the only problem now is the secondary reloads... :-((

Regards,
    Oleg.