This is the mail archive of the
mailing list for the GCC project.
Re: [PING] Target hook for rewriting inline asm constraints
"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 ;)