This is the mail archive of the
mailing list for the GCC project.
Re: reload question about unmet constraints
- From: DJ Delorie <dj at redhat dot com>
- To: "Ulrich Weigand" <uweigand at de dot ibm dot com>
- Cc: jim dot wilson at linaro dot org, gcc at gcc dot gnu dot org
- Date: Tue, 15 Sep 2015 12:17:00 -0400
- Subject: Re: reload question about unmet constraints
- Authentication-results: sourceware.org; auth=none
- References: <20150915155342 dot 8E85E2209 at oc7340732750 dot ibm dot com>
> 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 :-)