> And in fact, you should be able to decide at *expand* time which
> of the two you need for the given set of operands.

I already check for multiple fars at expand, and force all but one of
them to registers.  Somewhere before reload they get put back in.

>    "rl78_virt_insns_ok () && rl78_far_insn_p (operands)"

Since when does this work reliably?  I've seen cases where insns get
mashed together without regard for validity before...

I tested just this change - adding that function to addhi3 plus the
Wfr constraint sets - and it seems to work.  The big question to me
now is - is this *supposed* to work this way?  Or is is a coincidence
that the relevent passes happen to check that function?

> The Wfr constraint must not be marked as memory constraint (so as to
> avoid reload attempting to use it to access a stack slot).

This also prevents reload from reloading the address when it *is*
needed.  However, it seems to work ok even as a memory constraint.  Is
this change *just* because of the stack slots?  Could you give an
example of how it could be misused, so I can understand the need?

Reply via email to