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 D62D03858D33 for ; Tue, 6 Jun 2023 12:49:50 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org D62D03858D33 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 0603E2F4; Tue, 6 Jun 2023 05:50:36 -0700 (PDT) Received: from localhost (e121540-lin.manchester.arm.com [10.32.110.72]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id CB13C3F793; Tue, 6 Jun 2023 05:49:49 -0700 (PDT) From: Richard Sandiford To: Tamar Christina Mail-Followup-To: Tamar Christina ,"gcc-patches\@gcc.gnu.org" , nd , Richard Earnshaw , richard.sandiford@arm.com Cc: "gcc-patches\@gcc.gnu.org" , nd , Richard Earnshaw Subject: Re: [PATCH v2] machine descriptor: New compact syntax for insn and insn_split in Machine Descriptions. References: Date: Tue, 06 Jun 2023 13:49:48 +0100 In-Reply-To: (Tamar Christina's message of "Tue, 6 Jun 2023 12:00:55 +0000") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Status: No, score=-22.0 required=5.0 tests=BAYES_00,KAM_DMARC_NONE,KAM_DMARC_STATUS,KAM_LAZY_DOMAIN_SECURITY,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: 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. > 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