This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: reload question about unmet constraints


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]