> 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.
The RL78 has a segment register, much like the x86. The segment register allows you to have a 20-bit address instead of a 16-bit address. However, due to details of the port, you can only have *one* segment register override per operation, even if it applies to more than one (identical) operand. So, you can add two near pointers, but you can't add two different far pointers, but you can add something to a far pointer (i.e. x += 5). > 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. You can see why I'd rather not do that :-)
