This is the mail archive of the
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>
- Cc: GCC Development <gcc at gcc dot gnu dot org>
- Date: Tue, 1 Sep 2015 18:46:14 -0700
- Subject: Re: reload question about unmet constraints
- Authentication-results: sourceware.org; auth=none
- References: <201509010744 dot t817iv6A012061 at greed dot delorie dot com> <55E63993 dot 40700 at linaro dot org> <201509020120 dot t821KUur014778 at greed dot delorie dot com>
On Tue, Sep 1, 2015 at 6:20 PM, DJ Delorie <firstname.lastname@example.org> wrote:
>> It did match the first alternative (alternative 0), but it matched the
>> constraints Y/Y/m.
> It shouldn't match Y as those are for near addresses (unless it's only
> matching MEM==MEM), and the ones in the insn are far, but ...
Reload chooses the alternative that is the best match. When using the
constraints Y/Y/m, 2 of the three operands match the constraints, so
this ends up being the best match. It then tries to reload the far
mem to match Y, which fails, as all it knows how to do is reload a mem
address to make it match, which can't turn a far mem into a near mem.
You would need some way to indicate that while Y does accept a mem,
this particular mem can't be reloaded to match. We don't have a way
to do that.
The Y constraint gets classified as contraint type CT_MEMORY. In
find_reloads, in reload.c, there is a case CT_MEMORY, and it does
if (CONST_POOL_OK_P (operand_mode[i], operand)
|| MEM_P (operand))
badop = 0;
constmemok = 1;
offmemok = 1;
Since the operand is a MEM, badop is set to zero. That makes this
look like a good alternative. You want badop to be left alone. Also,
the fact that offmemok was set means that reload thinks that any mem
can be fixed by reloading the address to make it offsetable. You
don't want offmemok set. Without offmemok set, it should get reloaded
into a register, as reload will use the v constraint instead.