> Hi,
>
> I'm trying to add the movdi/movdf patterns to my HI target.
> Everything is working without this pattern, but it will bring further
> optimizations.
>
> The problem is that I'm not able to make it work. I have several reload
> issues and some questions to figure out how to fix them.
>
> - I first try to define it with a post reload define_plit and the
> constraints actually supported by HImode. But I'm getting an "unable to
> find a register to spill in class DATA_REGS". This occurs around
> function calls or lib calls which use 4 DATA_REGS class registers for
> params amoung 7, what seems to make reload impossible if parameters are
> allocated before the failed reload (?). I'm not sure of this... Any
> opinion on this?
I've just found the TARGET_SMALL_REGISTER_CLASSES_FOR_MODE_P hook which
seems to make things better. Is it supposed to completly fix the problem ?
> And is there a minimum number of registers in the class to make reload
> work around some function calls?
> - So I tried another option which seems to be less greedy: splitting
> after reload with a scratch HI reg and more general constraints (such as
> m:DI->m:DI through the scratch:HI), so does the m68hc11 target. The
> generated code is better, but I'm facing another reload issue with the
> insn that does not match its constraints, whereas it does for the 2
> operands. only the scratch register has not been allocated. Is it a
> matter of secondary_reload_info in TARGET_SECONDARY_RELOAD? What should
> be done?
> And once it will be fixed, should I define a tmp register and its
> associated constraint to pass to match_scratch to save a register when
> actually no scratch is needed ?
It seems actually the secondary_reload is able to use insn with scratch
register (from sri->icode). So no need to define an named movdi pattern
with such a scratch, right? And no need for a tmp reg...
But this does not explain why the scratch register has not been allocated.
BTW, I defined the IRA_COVER_CLASSES to the 2 classes of general
register classes of the target {DATA_REGS, ADDRESS_REGS}. If both
classes forms the GENERAL_REGS class, should I prefer defining
IRA_COVER_CLASSES = {GENERAL_REGS}, and handle moves between both
classes in secondary_reload using a scratch ?
Otherwise, I notice that when the IRA choses the best class, it cannot
fall back into the other class. Is it true ?
>
>
> Thank you by advance,
> Aurélien
