Jim Wilson wrote: > On Tue, Sep 15, 2015 at 7:42 AM, Ulrich Weigand <uweig...@de.ibm.com> wrote: > > But the only difference between define_memory_constraint and a plain > > define_constraint is just that define_memory_constraint guarantees > > that any memory operand can be made valid by reloading the address > > into a base register ... > > > > If the set of operands accepted by a constraint does *not* have that > > property, it must not be defined via define_memory_constraint, and > > you should simply use define_constraint instead. > > An invalid near mem can be converted to a valid near mem by reloading > its address into a base reg. An invalid far mem can be converted to a > valid far mem by reloading its address into a base reg. But one can't > convert a near mem to a far mem by reloading the address, nor can one > convert a far mem to a near mem by reloading its address. So we need > another dimension to the validity testing here, besides the question > of whether the address can be reloaded, there is the question of > whether it is in the right address space. Though I don't think the > rl78 is actually using address spaces, and it isn't clear if that > would help.
I see. Is it correct then to say that reload will never be able to change a near mem into a far mem or vice versa? If that is true, there doesn't appear to be any real benefit to having both near and far mem operations as *alternatives* to the same insn pattern. 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. Bye, Ulrich -- Dr. Ulrich Weigand GNU/Linux compilers and toolchain ulrich.weig...@de.ibm.com
