This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PING] Target hook for rewriting inline asm constraints
On 10/31/07, Andreas Krebbel <Andreas.Krebbel@de.ibm.com> wrote:
> Hi,
>
> > 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).
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?
Are you suggesting the rewriting for optimization (I think you do)? Or do you
believe there is no way you can keep correctness without the patch (I don't
believe that)?
> > 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.
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.
Richard.