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