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 98CCD3857C75 for ; Thu, 10 Sep 2020 23:01:26 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 98CCD3857C75 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 08AN0JxY028432; Thu, 10 Sep 2020 18:00:19 -0500 Received: (from segher@localhost) by gate.crashing.org (8.14.1/8.14.1/Submit) id 08AN0Irm028431; Thu, 10 Sep 2020 18:00:18 -0500 X-Authentication-Warning: gate.crashing.org: segher set sender to segher@kernel.crashing.org using -f Date: Thu, 10 Sep 2020 18:00:18 -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: <20200910230018.GX28786@gate.crashing.org> References: <20200909212238.GE28786@gate.crashing.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.4.2.3i X-Spam-Status: No, score=-7.7 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: Thu, 10 Sep 2020 23:01:28 -0000 On Thu, Sep 10, 2020 at 11:04:26AM +0100, Richard Sandiford wrote: > Segher Boessenkool writes: > > 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"). > > I guess it makes the description of other cores more verbose, but it > doesn't IMO make them more complicated. It's still just one test > against one attribute. And updating existing descriptions can be > done automatically by sed. Consider cores that do not care about the "subtype" at all: when using just "type", all cores have to test for "foo,foo_subtype", while with a separate attribute they can just test for "foo". A typical example in rs6000 is the "sign_extend" attribute for load instructions. All cores before power4 do not care at all about it. (Load and store insns get into combinatorial explosion land as well, as you discuss below, with "update" and "indexed" forms). > The difficulty with splitting into subattributes is that the tests in > the cores that *do* care then become more complicated. E.g. you have > to do: > > (ior (and (eq_attr "type" "foo") > (eq_attr "foo_subtype" "foo1")) > (eq_attr "type" "...others..")) > > and: > > (ior (and (eq_attr "type" "foo") > (eq_attr "foo_subtype" "!foo1")) > (eq_attr "type" "...others..")) > > instead of just: > > (eq_attr "type" "...") > > in both cases. Yes. It is a trade-off. > It's not too bad when it's just one subtype (like above), but it could > easily get out of hand. > > Perhaps in this case there's an argument in favour of having a separate > attribute due to combinatorial explosion. E.g. we have: > > - alu_shift_imm > - alus_shift_imm > - logic_shift_imm > - logics_shift_imm > > so having one attribute that describes the shift in all four cases > would perhaps be better than splitting each of them into two. Yeas, exactly. And for rs6000 we *did* have many more types before, and very frequently one was missed (in a scheduling description usually). Especially common was when some new type attribute was added, not all existing cpu descriptions were updated correctly. Maybe this is the strongest argument "for" actually :-) > Arguments in the other direction: > > - Once we have a separate attribute, it isn't clear where the line > should be drawn. Good taste ;-) > Alternatives include: > > (1) keeping the new attribute specific to shift immediates only > > (2) also having a “register” value, and folding: > alu_shift_imm, alu_shift_reg -> alu_shift > > (3) also having a “none” value, and doing away with the *_shift > type variants altogether: > alu_sreg, alu_shift_imm, alu_shift_reg -> alu_reg > > I think we should have a clear reason for whichever we pick, > otherwise we could be creating technical debt for later. Yes. One example of what we do: ;; Is this instruction using operands[2] as shift amount, and can that be a ;; register? ;; This is used for shift insns. (define_attr "maybe_var_shift" "no,yes" (const_string "no")) ;; Is this instruction using a shift amount from a register? ;; This is used for shift insns. (define_attr "var_shift" "no,yes" (if_then_else (and (eq_attr "type" "shift") (eq_attr "maybe_var_shift" "yes")) (if_then_else (match_operand 2 "gpc_reg_operand") (const_string "yes") (const_string "no")) (const_string "no"))) define_insns only use maybe_var_shift. Only the power6 and e*500* cpu descriptions ever look at var_shift. (Directly. There is some other scheduling code that looks at it too -- and all but the power6 ones seem to be incorrect! That is all a direct translation of "type-only" code there was before...) > - That approach is the opposite of what we did for the neon_* attributes: > every type has a q variant, rather than the size being a separate > attribute. > > FWIW, we shouldn't assume that this distinction is specific to a64fx. :-) Yeah, absolutely. This classifies instructions, of course it is very strongly influenced by what scheduling descriptions want, but it helps a lot if you describe more general characteristics :-) Segher