This is the mail archive of the
mailing list for the GCC project.
Question regarding constraint usage within inline asm
- From: Peter Bergner <bergner at linux dot ibm dot com>
- To: GCC <gcc at gcc dot gnu dot org>
- Date: Mon, 18 Feb 2019 13:13:31 -0600
- Subject: Question regarding constraint usage within inline asm
I have a question about constraint usage in inline asm when we have
an early clobber output operand. The test case is from PR89313 and
looks like the code below (I'm using "r3" for the reg on ppc, but
you could also use "rax" on x86_64, etc.).
register long output asm ("r3");
asm ("blah %0, %1, %2" : "=&r" (output) : "r" (input), "0" (input));
I know an input operand can have a matching constraint associated with
an early clobber operand, as there seems to be code that explicitly
mentions this scenario. In this case, the user has to manually ensure
that the input operand is not clobbered by the early clobber operand.
In the case that the input operand uses an "r" constraint, we just
ensure that the early clobber operand and the input operand are assigned
different registers. My question is, what about the case above where
we have the same variable being used for two different inputs with
constraints that seem to be incompatible? Clearly, we cannot assign
a register to the "input" variable that is both the same and different
to the register that is assigned to "output".
Is this outright invalid to have "input" use both a matching and
non-matching constraint with an early clobber operand? Or is is
expected that reload/LRA will come along and fix up the "r" usage
to use a different register?
My guess is that this is invalid usage and I have a patch to
expand_asm_stmt() to catch this, but it only works if we've
preassigned "output" to a hard register. If this is truly
invalid, should I flag this even if "output" isn't preassigned?
If it is valid, then should match_asm_constraints_1() really rewrite
all of the uses of "input" with the register assigned to output as
it is doing now, which is what is causing the problems in LRA.
LRA sees that both input operands are using r3 and it catches the
constraint violation of the "r" input and tries to spill it, but
it's not a pseudo, but an explicit hard register already. I'm not
sure LRA can really safely spill an operand that is an explicit hard