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] [PATCH] Fix asm X constraint (PR inline-asm/59155)


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


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