This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


Hi,

> Why not leave "m" as is, even with the new addressing mode and add a
> new constraint allowing the new base + index addressing mode.  This way
> existing patterns and inline asm will continue to work (it couldn't know about
> the new addressing mode or instructions anyway) and if one wants to use
> the new stuff use the new constraint?

Unfortunately this is not possible.  The problem is that the
GO_IF_LEGITIMATE_ADDRESS_P hook is coupled to the "m" constraint.
Currently it isn't possible to change one without the other.  But you
*have* to add the new addressing mode the GO_IF_LEGITIMATE_ADDRESS_P
hook otherwise these addresses would never pass the reload step.

The definition of the "m" constraint is to accept every possible
address the back end accepts.  Or in the words of the interals manual:

m: "A memory operand is allowed, with any kind of address that the
machine supports in general."

So you actually can't support new addressing formats in the back end
without changing the semantics of it.  The proper way would be to
disallow the "m" constraint in inline assemblies but thats probably a
bit late ;)

> The only thing I could imagine would be that the new architecture forces
> you to use base + index addressing, but only on _some_ insns.  So where
> 
>   insn0 %0
>   insn1 %1
> 
> with both "m" constraints would be valid before, only (and truly only) the
> second insn1 is now forced to do base + index addressing?  That is, you
> have to split semantics of "m" based on the instruction it is used in?
> Which is the root of my doubt that you can automatically rewrite "m"s
> in any case - or proves that this is not the situation you need to handle.

I must admit that it is probably are rare case that an architecture
changes so fundamentally that new address types are supported.  But
actually we already had such a change for S/390 - with the long
displacement extension.  Originally only Base + Index + 12 bit
displacement addresses were supported.  With the long displacement
facility the discplacement was extended to 20 bit.  Fortunately most
of the instructions dealing with memory were extended transparently so
it was decided to leave it as is but for 100% correctness we would
have needed a mechanism like the "inline asm constraint rewrite hook"
already for that change.

Bye,

-Andreas-


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]