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 ED2243857C59 for ; Wed, 9 Sep 2020 21:23:45 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org ED2243857C59 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 089LMdSV004444; Wed, 9 Sep 2020 16:22:39 -0500 Received: (from segher@localhost) by gate.crashing.org (8.14.1/8.14.1/Submit) id 089LMdbG004430; Wed, 9 Sep 2020 16:22:39 -0500 X-Authentication-Warning: gate.crashing.org: segher set sender to segher@kernel.crashing.org using -f Date: Wed, 9 Sep 2020 16:22:38 -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: <20200909212238.GE28786@gate.crashing.org> References: 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.9 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: Wed, 09 Sep 2020 21:23:47 -0000 Hi! On Mon, Sep 07, 2020 at 09:20:59PM +0100, Richard Sandiford wrote: > This is just personal opinion, but in general (from the point of view > of a new port, or a new subport like SVE), I think the best approach > to handling the "type" attribute is to start with the coarsest > classification that makes sense, then split these relatively coarse > types up whenever there's a specific need. Agreed. > When taking that approach, it's OK (and perhaps even a good sign) > for an existing type to sometimes be too coarse for a new CPU. > > So thanks for asking about this, and please don't feel constrained > by the existing "type" classification. IMO we should split existing > types wherever that makes sense for new CPUs. You can also use some other attributes to classify instructions, you don't have to put it all in one "type" attribute. This can of course be done later, at a time when it is clearer what a good design will be. Sometimes it is obvious from the start though :-) (This primarily makes the pipeline descriptions much simpler, but also custom scheduling code and the like. If one core has two types of "A" insn, say "Aa" and "Ab", it isn't nice if all other cores now have to handle both "Aa" and "Ab" instead of just "A"). Segher