This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PING] [PATCH] Fix asm X constraint (PR inline-asm/59155)
- From: Jeff Law <law at redhat dot com>
- To: Bernd Edlinger <bernd dot edlinger at hotmail dot de>, Jakub Jelinek <jakub at redhat dot com>
- Cc: Vladimir Makarov <vmakarov at redhat dot com>, "gcc-patches at gcc dot gnu dot org" <gcc-patches at gcc dot gnu dot org>, Richard Biener <rguenther at suse dot de>, Marc Glisse <marc dot glisse at inria dot fr>
- Date: Thu, 9 Jun 2016 10:28:33 -0600
- Subject: Re: [PING] [PATCH] Fix asm X constraint (PR inline-asm/59155)
- Authentication-results: sourceware.org; auth=none
- References: <AM4PR07MB157116B6325547B97D4C148CE4400 at AM4PR07MB1571 dot eurprd07 dot prod dot outlook dot com> <AM4PR07MB157148DEF55A9C540991A296E45C0 at AM4PR07MB1571 dot eurprd07 dot prod dot outlook dot com> <5755AD05 dot 4010608 at redhat dot com> <b143b78e-688d-b1b4-4094-9c8ebd50b1ea at redhat dot com> <20160606180128 dot GC7387 at tucnak dot redhat dot com> <ff20dba7-b480-07a4-4c71-1cbef1dba384 at redhat dot com> <20160606180845 dot GD7387 at tucnak dot redhat dot com> <AM4PR07MB157165C1603824FE47A6C74FE45D0 at AM4PR07MB1571 dot eurprd07 dot prod dot outlook dot com>
On 06/07/2016 11:58 AM, Bernd Edlinger wrote:
AFACT this is not the only place where overly complex RTL trees can
cause an ICE.
That wouldn't surprise me at all -- but the design of RTL is such that
it can be arbitrarily complex. Essentially, routines can not make
assumptions about the complexity of the RTL they're given -- except for
any guards/pre-conditions set up in the caller.
Yes. That is what I think too, "X" is probably not used often in
practice, but if it is allowed, it should at least not result in an ICE.
There's no disagreement about "X" should never result in an ICE.
The question is whether or not "X" truly means an arbitrary piece of RTL
or some tighter subset of RTL. I guess one could also raise the
question of whether or not "X" should ever be exposed to asms.
"X"'s original intent IIRC was to specify that for a particular
alternative the operand didn't matter and would never be used. This
comes up with scratch registers for example.
"X" should allow to feed "whatsoever" valid C expressions to the asm
input, and using the %-expression in the assembler string should not
cause an ICE.
Actually it doesn't even have to be a valid C expression. It might have
started as a C expression from an ASM statement, but been modified by
various RTL optimization passes into something that isn't necessarily a
valid C expression.
However if I compare commond.md ...
(define_constraint "i"
"Matches a general integer constant."
(and (match_test "CONSTANT_P (op)")
(match_test "!flag_pic || LEGITIMATE_PIC_OPERAND_P (op)")))
... against recog.c, general_operand seems to allow less i.e. checks
targetm.legitimate_constant_p additionally. So that is something
I don't really understand, I mean if a constant is not a "legitimate"
constant by the target's definition, why should it be safe to use
in later in targetm.asm_out.print_operand?
Legitimacy in this context is usually something related to operands that
have to be reloaded for PIC code generation. They may print just fine,
but from a code generation standpoint they require special handling.
One could argue that this is inconsistent and it ought to be cleaned up,
but that's separate from the "X" issue.
jeff