DJ Delorie wrote: > > 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.
OK, that's good. > Somewhere before reload they get put back in. To avoid that, you need a check like this: > > "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? This certainly supposed to work reliably. Every pass that changes an insn is supposed to re-recognize it, and that will check the operand predicates as well as the overall insn predicate. Note that there are some exceptions, in particular reload, which will make certain types of changes to insn operands *without* fully revalidating the insn, because it simply assumes those changes are safe. That's why in addition to the insn predicate, you also need to constrain reload's possible actions to those that are guaranteed to not break the predicate. > > 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? If the constraint is marked as "memory constraint", reload will assume that everything that is forced to memory by reload can be handled by this alternative. This includes: - a pseudo that was forced to a stack slot - a pseudo that is REG_EQUIV to some memory location - any memory operand whose address already had to be reloaded since it was not legitimate - any immediate that was forced to the constant pool (and possibly others that I'm not thinking of right now). So in general, it's really not safe to mark a constraint that accepts only far memory as "memory constraint" with current reload. Note that *not* marking the constraint as memory constraint actually does not prevent reload from fixing up illegitimate addresses, so you shouldn't really see much drawbacks from not marking it ... (You really need the memory constraint marker for constraints that accept only a *subset* of legitimate addresses, so that reload will attempt to reload even addresses that would otherwise be considered legitimate.) Bye, Ulrich -- Dr. Ulrich Weigand GNU/Linux compilers and toolchain ulrich.weig...@de.ibm.com