On Mon, Sep 14, 2015 at 11:05 PM, DJ Delorie <d...@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. We already have constraint_satisfied_p, which is generated from define*_constraint. We could have a constraint_reloadable_to_match_p function parallel to that, which is for operands that don't match, but can be reloaded to match. Perhaps we don't even need a distinction between define_memory_constraint and define_special_memory_constraint. We could have constraint_reloadable_to_match_p default to the current code for memory constraints, that assumes any mem is reloadable to match, if a special reloadable condition isn't specified. Perhaps define_memory_constraint can be extended with an optional field at the end, that is used to generate the constraint_reloadable_to_match_p function. Otherwise, I think you are headed in the right direction. I would worry a bit about whether we are making reload even more complicated for folks. But given that we already have the concept of address spaces, there should be some way to expose this info to reload. Jim
