[PING] Target hook for rewriting inline asm constraints

Andreas Krebbel Andreas.Krebbel@de.ibm.com
Wed Nov 7 11:55:00 GMT 2007


> 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.

I was thinking about the usage of that new "all valid memory
addresses" constraint in the back end.  That constraint letter will
only be usable for instructions which support the old as well as the
new address format which is probably a rare case.  I was hoping that
this could be improved when having a target hook with extra logic
instead of a macro but I don't think anymore that this would help.

Another thing I was worrying about was that for an inline assembly
using the "m" constraint different (maybe worse) code can be generated
when "m" is handled as extra constraint instead of as standard memory
constraint.  That wouldn't be a problem with the target hook returning
"m" for previous archs since the standard "m" codepath would be taken.
But at least for reload this does not seem to be a problem.  The code
handling extra memory constraints matches what is done for the "m"
case.

To sum up I think you've convinced me that the target macro will do
the job and is simpler to implement than the rewriting hook.  As next
step I would like to give the "let the back end redefine standard
constraints" idea a whirl and will come back to your target macro if
this doesn't turn out to be feasible.  Thanks for your suggestions!

> True.  Is s390 out of single constraint letters?

Not yet. But there are not many left.
 
> > 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 ;)

I'll post a patch.

Bye,

-Andreas-



More information about the Gcc-patches mailing list