This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: reload question about unmet constraints
- From: Jim Wilson <jim dot wilson at linaro dot org>
- To: DJ Delorie <dj at redhat dot com>, gcc at gcc dot gnu dot org
- Date: Tue, 1 Sep 2015 16:49:39 -0700
- Subject: Re: reload question about unmet constraints
- Authentication-results: sourceware.org; auth=none
- References: <201509010744 dot t817iv6A012061 at greed dot delorie dot com>
On 09/01/2015 12:44 AM, DJ Delorie wrote:
> I expected gcc to see that the operation doesn't meet the constraints,
> and move operands into registers to make it work (alternative 1,
> "v/v/v").
It did match the first alternative (alternative 0), but it matched the
constraints Y/Y/m. Operands 1 and 2 are OK, so don't need reloads. It
did create optional reloads, which it always does for mem, but these
reloads are irrelevant. The interesting one is for operand 0. Since Y
accepts mem, and operand 0 is a mem but doesn't match, reload assumes
that we can fix it by reloading the address to make it an offsettable
address. But a far mem is still not acceptable even with a reloaded
address, and you get an ICE.
Reload doesn't have any concept of two different kinds of memory
operands which can't be converted via reloads. If the constraint
accepts mem, and we have a mem operand, then it will always assume that
the problem is with the address and reload it.
I don't think that there is an easy solution to this, but my reload
skills are a bit rusty too.
Jim