Re: reload question about unmet constraints

["Ulrich Weigand" <uweigand at de dot ibm dot com>]

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.Weigand@de.ibm.com