Re: [PING] Target hook for rewriting inline asm constraints

[Richard Sandiford <rsandifo@nildram.co.uk>]

"Andreas Krebbel" <Andreas.Krebbel@de.ibm.com> writes:
>> Well, I was thinking of making it a macro constant; I should have picked
>> a name other than TARGET_MEM_CONSTRAINT, sorry.
>> 
>> It might be nice to define the macro indirectly using a new constraints.md
>> construct (define_general_memory_constraint?).  I.e. have genpreds define
>> the macro for you based on the .md file.  The implementation could then
>> move away from macros at the same time as the rest of the constraints
>> stuff does[*].  I think that'd still be easier than converting gcc/*.c
>> to treat 'm' as a hook (and easier than rewriting asms).  But personally,
>> I'd be happy enough if the macro was defined in the target .h file.
>
> One disadvantage of a target macro used in case expressions is that we
> can't check the arch flags here.  So the logic would have to go into
> the constraint definition.  The new constraint letter will have to
> accept the new address format as well as the old one for the new
> architecture and just the old address format for all former archs.

Maybe I'm misunderstanding what you want, but I thought we were
simply talking about renaming the "all valid memory addresses"
constraint from 'm' to some target-specific value.  That renamed
constraint would be treated exactly as 'm' is treated now, without
the need for any special back-end code to handle it.

> If we would have a target hook here which would return the new mem
> constraint letter if the arch flag for the new architecture is set and
> 'm' otherwise, the new constraint letter would not have to depend on
> arch flags what I would personally prefer.
>
> Another disadvantage is that this would prevent usage of multiple
> letter constraints for the standard mem constraint.

True.  Is s390 out of single constraint letters?

> What about the idea of letting the back end override all the existing
> standard constraints using the existing constraint definitions.
> Reload and co could check whether a back end accepts one of the
> standard constraint letters as extra constraint and would fallback to
> the standard behaviour if not.

That sounds OK too, although I'm not the one you need to convince ;)

Richard