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