On 06/06/16 20:08, Jakub Jelinek wrote:
> On Mon, Jun 06, 2016 at 12:04:04PM -0600, Jeff Law wrote:
>> On 06/06/2016 12:01 PM, Jakub Jelinek wrote:
>>> On Mon, Jun 06, 2016 at 11:54:04AM -0600, Jeff Law wrote:
>>>>> As for recog.c, I can not approve this as I am not a maintainer of it.
>>>>> I only can say that the code looks questionable to me.
>>>> I think the question on the recog part is a matter of how we choose to
>>>> interpret what the "X" constraint means.
>>>>
>>>> Does it literally mean accept anything, or accept some subset expressions?
>>>>
>>>> I tend to think the former, which means that things like
>>>> reg_overlap_mentioned_p or its callers have to be bullet-proofed.
AFACT this is not the only place where overly complex RTL trees can
cause an ICE.
>>>
>>> I think it is a bad idea to accept really anything, even for debug insns,
>>> which initially accepted arbitrarily large RTL expressions (and still accept
>>> stuff like subregs otherwise considered invalid etc.) we found it is highly
>>> undesirable, as it is not very good idea for the compile time complexity
>>> etc., so now we are trying to limit the complexity of the expressions there
>>> by splitting up more complex expressions into smaller ones using
>>> temporaries.
>>> So, even accept anything should always be accept anything reasonable,
>>> because most of the RTL passes don't really expect arbitrarily deep
>>> expressions, or expressions where the same reg can appear thousands of times
>>> etc.
>> The problem is how do you define this subset of expressions you're going to
>> accept and those which you are going to reject.
>>
>> I first pondered accepting RTL leaf nodes (reg, subreg, constants) and
>> rejecting everything else. But I couldn't convince myself that some port
>> might reasonably expect (plus (x) (y)) to match the "X" constraint.
>
> It is always going to be arbitrary.
> Perhaps RTL leaf nodes (if including MEM, then perhaps with valid address
> only), and unary/binary/ternary RTL expressions with RTL leaf node operands?
> Or union of what is accepted by any other constraint?
> Or "g" plus any constants?
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.
"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.
And "X" really means different "whatsoever" things in asm statements
and in .md files, even md.texi has different text for internally used
"X" constraint and assembler "X" constraint, so that should be OK.
According to md.texi
"g" should already mean:
@item @samp{g}
Any register, memory or immediate integer operand is allowed, except for
registers that are not general registers.
Which is the same as general_operand(op, VOIDmode). And in other words,
that should be everything that is in "r", "m" and "i" constraints.
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?
Bernd.
