This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: reload question about unmet constraints
- From: "Ulrich Weigand" <uweigand at de dot ibm dot com>
- To: jim dot wilson at linaro dot org (Jim Wilson)
- Cc: dj at redhat dot com (DJ Delorie), gcc at gcc dot gnu dot org (GCC Development)
- Date: Tue, 15 Sep 2015 16:42:31 +0200 (CEST)
- Subject: Re: reload question about unmet constraints
- Authentication-results: sourceware.org; auth=none
Jim Wilson wrote:
> On Mon, Sep 14, 2015 at 11:05 PM, DJ Delorie <dj@redhat.com> wrote:
> > As a test, I added this API. It seems to work. I suppose there could
> > be a better API where we determine if a constrain matches various
> > memory spaces, then compare with the memory space of the operand, but
> > I can't prove that's sufficiently flexible for all targets that
> > support memory spaces. Heck, I'm not even sure what to call the
> > macro, and "TARGET_IS_THIS_MEMORY_ADDRESS_RELOADABLE_TO_MATCH_THIS_CONTRAINT_P()"
> > is a little long ;-)
> >
> > What do we think of this direction?
>
> We already have define_constraint and define_memory_constraint. We
> could perhaps add a define_special_memory_constraint that returns
> CT_SPECIAL_MEMORY which mostly operates like CT_MEMORY, except that it
> doesn't assume any MEM can be reloaded to match.
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.
Bye,
Ulrich
--
Dr. Ulrich Weigand
GNU/Linux compilers and toolchain
Ulrich.Weigand@de.ibm.com