This is the mail archive of the gcc@gcc.gnu.org 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: Problem with reloading in a new backend...


Le mercredi 09 avril 2008 Ã 18:21 -0400, DJ Delorie a Ãcrit :
> > Maybe I should reserve a special register for this usage (say r0).
> 
> That might be the only way, yes.

Ok, I reserved r0 (BP_REGNUM) for such reloads, and I'm generating new
instructions in LEGITIMIZE_RELOAD_ADDRESS to calculate the memory
address:

        if (GET_CODE (*x) == PLUS
            && GET_CODE (XEXP (*x, 0)) == REG
            && GET_CODE (XEXP (*x, 1)) == CONST_INT) {
                rtx reginsn, setinsn, plusinsn;
                reginsn = gen_rtx_REG(Pmode, BP_REGNUM);
                setinsn = gen_rtx_SET(Pmode, reginsn, XEXP (*x, 1));
                plusinsn = gen_rtx_SET(Pmode, reginsn, gen_rtx_PLUS(Pmode, reginsn, XEXP (*x, 0)));

                emit_insn_before(setinsn, insn);
                emit_insn_before(plusinsn, insn);
                *x = reginsn;

                return 1;
        }

Does this sound ok ?

Note that I needed to use emit_insn_before() in order to insert the
instructions, and emit_insn_before() needs the current 'insn', which
is not passed by LEGITIMIZE_RELOAD_ADDRESS(), so I needed to modify the
macro. Is there something I miss here ?

> Note that reload also assumes that such adds don't change the flags
> (i.e.  a compare/jump pair must not have a flag-modifying add between
> them).

I think this won't happen because I emit the compare/conditional branch
insn at the same time, in beq/bne/bgt... etc define_insn() (like many
other targets).

Thanks.
-- 
Stelian Pop <stelian@popies.net>


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