DJ Delorie wrote:
> > In that case, you might be able to fix the bug by splitting the
> > offending insns into two patterns, one only handling near mems
> > and one handling one far mems, where the near/far-ness of the mem
> > is verified by the *predicate* and not the constraints.
>
> But this means that when reload needs to, it moves far mems into
> registers, which changes which insn is matched... It also adds a
> *lot* of new patterns, since any of the three operands can be far, and
> '0' constraints on far are allowed also - and most insns allow far
> this way, so could be up to seven times as many patterns.
I still think you should get by with two patterns, basically one that
represents the case where you emit an override, and one for the case
without override.
And in fact, you should be able to decide at *expand* time which
of the two you need for the given set of operands. It may be
that you'll have to load a far mem into a register here, at
expand time, if none of the two cases would otherwise match.
This is best done at expand, since there's really nothing
reload can do any better even if you wait until then.
Then you need to ensure that reload will not accidentally switch
that decision again, so you'll probably need constraints after all.
Something like this ought to work:
(define_insn "*add<mode>3_virt_far"
[(set (match_operand:QHI 0 "rl78_nonimmediate_operand" "=Wfr,v,v")
(plus:QHI (match_operand:QHI 1 "rl78_general_operand" "vi0,Wfr,vi")
(match_operand:QHI 2 "rl78_general_operand" "vi0,vi1,Wfr")))
]
"rl78_virt_insns_ok () && rl78_far_insn_p (operands)"
"v.add\t%0, %1, %2"
)
(define_insn "*add<mode>3_virt_near"
[(set (match_operand:QHI 0 "rl78_nonfar_nonimm_operand" "=vY,S")
(plus:QHI (match_operand:QHI 1 "rl78_nonfar_operand" "viY,0")
(match_operand:QHI 2 "rl78_nonfar_operand" "viY,i")))
]
"rl78_virt_insns_ok ()"
"v.add\t%0, %1, %2"
)
[It might be possible to emit both patterns from a single macro.]
rl78_far_insn_p needs to be a function that returns true if there is
exactly one, possibly duplicated, operand that is a far mem.
The Wfr constraint must not be marked as memory constraint (so as to avoid
reload attmpting to use it to access a stack slot). But the Y constraint
*can* be marked as memory constraint.
Bye,
Ulrich
--
Dr. Ulrich Weigand
GNU/Linux compilers and toolchain
ulrich.weig...@de.ibm.com
