This is the mail archive of the 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


> I also wonder how you can distinguish between "old" and "new" "m" used
> in asms.  How do you know which semantics the user chose?  IMHO
> "semantics" of asm constrains should never change, but instead you should
> introduce new machine specific constraints if necessary.

Actually the point of the target hook is to prevent the "m" constraint
semantics from changing when the back end changes.

Consider the case you want to add a new instruction to a back
end. This new instruction supports loading a value from memory
locations given by base + index register.  All the existing
instructions just accepted a single base register as memory address.
In order to prevent reload from trying to reload all base + index
addresses into a single base address register you have to change the
GO_IF_LEGITIMATE_ADDRESS hook to accept base + index addresses.  This
change would depend on the availability of the new instruction
supporting base + index like addresses so most likely it would depend
on an architecture flag.

As a consequence the "m" constraint also would accept base + index
addresses for the added architecture.  Unfortunately this breaks all
places where one of the old instructions is coupled to the "m"
constraint.  Instruction patterns in the back end using the "m"
constraint have to be changed.  The straightforward solution would be
to add a new constraint letter accepting memory addresses with just a
single base register and replace all occurrences of "m" with that new
constraint letter.

But unfortunately our internally used constraint letters are exposed
to the GCC user via the GCC inline assembly construct.  So if you have
an inline assembly containing one of the old instructions accepting
just a base as address its operand constraint is probably the "m"
constraint.  If you now would compile the very same inline assembly
setting the architecture flag which makes the back end to enable base
+ index addresses GCC will pass a base + index address for that
operand which would make gas to complain about that instruction.

The problem is that the "m" semantics changed but not the instruction
in the inline assembly.

To distingiush between the different "m" constraint versions the back
end hook has to use the same logic which will be added to
GO_IF_LEGITIMATE_ADDRESS.  The new hook should replace every
occurrence of "m" in an inline assembly operand list with the
constraint letter for the former address format and it only has to do
it for architecture flags which would change the behaviour of
GO_IF_LEGITIMATE_ADDRESS (although it wouldn't be a problem to
always do the rewrite).

> The patch doesn't come with a testcase or an example showing how this
> should work or how it would break without it, so it's hard to tell if you
> have a point.  But in general - asm constrains rewriting?? uh no.

I don't have a testcase yet.  But my explanations above probably give
you an idea why this target hook is necessary sooner or later.



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