From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from gate.crashing.org (gate.crashing.org [63.228.1.57]) by sourceware.org (Postfix) with ESMTP id C97EB3857C62 for ; Mon, 14 Sep 2020 18:42:59 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org C97EB3857C62 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=kernel.crashing.org Authentication-Results: sourceware.org; spf=fail smtp.mailfrom=segher@kernel.crashing.org Received: from gate.crashing.org (localhost.localdomain [127.0.0.1]) by gate.crashing.org (8.14.1/8.14.1) with ESMTP id 08EIfqCT008024; Mon, 14 Sep 2020 13:41:53 -0500 Received: (from segher@localhost) by gate.crashing.org (8.14.1/8.14.1/Submit) id 08EIfqlN008023; Mon, 14 Sep 2020 13:41:52 -0500 X-Authentication-Warning: gate.crashing.org: segher set sender to segher@kernel.crashing.org using -f Date: Mon, 14 Sep 2020 13:41:52 -0500 From: Segher Boessenkool To: "Qian, Jianhua" , "gcc@gcc.gnu.org" , richard.sandiford@arm.com Subject: Re: A problem with one instruction multiple latencies and pipelines Message-ID: <20200914184152.GZ28786@gate.crashing.org> References: <20200909212238.GE28786@gate.crashing.org> <20200910230018.GX28786@gate.crashing.org> <20200911135853.GY28786@gate.crashing.org> <8417a22bbdd44efcb2309e07510d1515@G08CNEXMBPEKD06.g08.fujitsu.local> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-Spam-Status: No, score=-7.6 required=5.0 tests=BAYES_00, JMQ_SPF_NEUTRAL, KAM_DMARC_STATUS, TXREP, T_SPF_HELO_PERMERROR, T_SPF_PERMERROR autolearn=no autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: gcc@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Sep 2020 18:43:01 -0000 Hi! On Mon, Sep 14, 2020 at 10:55:35AM +0100, Richard Sandiford wrote: > "Qian, Jianhua" writes: > > - If we cannot resolve it, the existing CPUs' descriptions need to be changed. This is not what I expected. > > - If we want to add new attribute to resolve this problem, why not use the Case1 directly? > > It's a trade-off. At the moment the rule for arm and aarch64 is simple: > the "type" attribute specifies the complete scheduling type. If we > instead change policy and divide the information among several attributes, > those attributes will have increasingly complex relationships with one > another. It will become easier to specify a meaningless combination > by mistake, or to forget to specify one of the relevant attributes. I found exactly the opposite, when I did this to rs6000: this is much *less* error-prone. > I agree it's not so bad with just one extra attribute. The question > is more: if we change the policy, what would things look like if there > were more attributes of a similar nature? You often can do new attributes that apply to quite a few different instructions. Like, as an extreme example, we have ;; What data size does this instruction work on? ;; This is used for insert, mul and others as necessary. (define_attr "size" "8,16,32,64,128" (const_string "32")) But there also is ;; Is this instruction record form ("dot", signed compare to 0, writing CR0)? ;; This is used for add, logical, shift, exts, mul. (define_attr "dot" "no,yes" (const_string "no")) and a few more. But just that: a few. It isn't good to have very many extra attributes, in the same way that very many insn types makes things harder than needed. > On the other side, lumping everything into one attributes gives a > long list of values. I think the difference of opinion is that Segher > finds this argument more compelling while I find the other argument > more compelling ;-) It's a trade-off, we agree on that :-) And I'd be conservative here, we agree on that as well. > Although this looks/sounds complicated, the advantage is that everything > remains up-to-date. If we instead added a second attribute and only > defined it for instructions like *add__, other instructions > (including config/arm instructions) would still have type alu_shift_imm > but would have a shift_imm_value of "none". I would make an attribute for the mode (or data size really), and one that says the insn uses shifted data (since many arm insns have that, just like record form on PowerPC is everywhere). And you can have that one filled "by magic" usually! Segher