From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by sourceware.org (Postfix) with ESMTP id 1DE173858D33 for ; Tue, 6 Jun 2023 16:13:27 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 1DE173858D33 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=arm.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=arm.com Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id EA99B2F4; Tue, 6 Jun 2023 09:14:11 -0700 (PDT) Received: from [10.2.78.54] (e120077-lin.cambridge.arm.com [10.2.78.54]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id ABA3F3F6C4; Tue, 6 Jun 2023 09:13:25 -0700 (PDT) Message-ID: Date: Tue, 6 Jun 2023 17:13:24 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.11.0 Subject: Re: [PATCH v2] machine descriptor: New compact syntax for insn and insn_split in Machine Descriptions. Content-Language: en-GB To: Tamar Christina , "gcc-patches@gcc.gnu.org" , nd , richard.sandiford@arm.com References: From: "Richard Earnshaw (lists)" In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-3492.9 required=5.0 tests=BAYES_00,KAM_DMARC_NONE,KAM_DMARC_STATUS,KAM_LAZY_DOMAIN_SECURITY,NICE_REPLY_A,SPF_HELO_NONE,SPF_NONE,TXREP,T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On 06/06/2023 13:49, Richard Sandiford via Gcc-patches wrote: > Tamar Christina writes: >>>> int operand_number; /* Operand index in the big array. */ >>>> int output_format; /* INSN_OUTPUT_FORMAT_*. */ >>>> + bool compact_syntax_p; >>>> struct operand_data operand[MAX_MAX_OPERANDS]; }; >>>> >>>> @@ -700,12 +702,57 @@ process_template (class data *d, const char >>> *template_code) >>>> if (sp != ep) >>>> message_at (d->loc, "trailing whitespace in output template"); >>>> >>>> - while (cp < sp) >>>> + /* Check for any unexpanded iterators. */ >>>> + if (bp[0] != '*' && d->compact_syntax_p) >>> >>> I assume the bp[0] != '*' condition skips the check for C code blocks. >>> Genuine question, but are you sure we want that? C code often includes asm >>> strings (in quotes), such as for the SVE CNT[BHWD] example. >>> >>> Extending the check would mean that any use of <...> for C++ templates will >>> need to be quoted, but explicit instantiation is pretty rare in .md files. It would >>> also look weird for conditions. >>> >>> Either way is fine, just asking. >> >> I excluded it entirely to avoid also running afoul of the binary operators. So e.g. >> * a < b && b > c ? foo : bar shouldn't trigger it. It seemed more trouble than it's >> worth to try to get correct. > > Yeah. I agree it's probably better to skip. > >>>> + } >>>> + >>>> + /* Adds a character to the end of the string. */ void add (char >>>> + c) { >>>> + con += c; >>>> + } >>>> + >>>> + /* Output the string in the form of a brand-new char *, then effectively >>>> + clear the internal string by resetting len to 0. */ char * out >>>> + () >>> >>> Formatting: no need for a space before "out". >>> >>>> + { >>>> + /* Final character is always a trailing comma, so strip it out. >>>> + */ >>> >>> trailing ',', ';' or ']', rather than just a comma? >> >> Ah no, this is a bit of a lazy intercalate, when the alternatives are pushed in it's >> not easy to tell how many there will be (because we don't keep track of it in this part), >> so we just always add a trailing "," and ignore the last char on output. Validation of the >> alternative counts themselves is done later by the normal machinery. > > Ah, I get it now, thanks. > >>>> + } >>>> + >>>> + return index; >>>> +} >>>> + >>>> +/* Modify the attributes list to make space for the implicitly declared >>>> + attributes in the attrs: list. */ >>>> + >>>> +static void >>>> +create_missing_attributes (rtx x, file_location /* loc */, >>>> +vec_conlist &attrs) { >>>> + if (attrs.empty ()) >>>> + return; >>>> + >>>> + unsigned int attr_index = GET_CODE (x) == DEFINE_INSN ? 4 : 3; >>>> + vec_conlist missing; >>>> + >>>> + /* This is an O(n*m) loop but it's fine, both n and m will always be very >>>> + small. */ >>> >>> Agreed that quadraticness isn't a problem. But I wonder how many people >>> would write an explicit placeholder set_attr. Unlike match_operand and >>> match_scratch, a placeholder set_attr doesn't carry any additional >>> information. >>> >>> It might be simpler to drop add_attributes and add all attributes >>> unconditionally in this function instead. If the user tries to specify the same >>> attribute using both syntaxes, the pattern would end up with two definitions >>> of the same attribute, which ought to be flagged by existing code. >>> >> >> This was done to support the (in arm backend) common thing of having attributes >> which are either too complex to add inline in the new syntax or that just repeat a >> value. >> >> i.e. it's to allow cases like this: >> >> [(set_attr "length") >> (set_attr "predicable" "yes") >> (set_attr "predicable_short_it") >> (set_attr "arch") >> (set (attr "type") (if_then_else (match_operand 2 "const_int_operand" "") >> (const_string "alu_imm") >> (const_string "alu_sreg"))) >> >> Where your attrs contains: >> >> {@ [cons: =0, 1, 2; attrs: length, predicable_short_it, arch] > > Yeah, agree it needs to be possible to define things like "type" > in this way. You also want it for the case where every alternative takes the same value, eg the "predicable - yes" attr. R. > >> However you're right, I could simply say that you must omit the set_attr in attrs and just >> merge the two lists? I think that's what you were alluding to? > > Yeah, that's right. Or just concatenate them and rely on later > error checking (which should give reasonable diagnostics). > > Thanks, > Richard