From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-sender-0.a4lg.com (mail-sender.a4lg.com [153.120.152.154]) by sourceware.org (Postfix) with ESMTPS id C06DA3858C52 for ; Fri, 23 Sep 2022 07:13:38 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org C06DA3858C52 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=irq.a4lg.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=irq.a4lg.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by mail-sender-0.a4lg.com (Postfix) with ESMTPSA id CEA22300089; Fri, 23 Sep 2022 07:13:35 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=irq.a4lg.com; s=2017s01; t=1663917215; bh=pL/DiEdr/nrnFaMn7bC+806Pg6bl8zIqbARkl+m36y8=; h=Message-ID:Date:Mime-Version:Subject:To:References:From: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=Ks65dMGS2DaB/mlfN8F3Z3l3WJxmGEaz3KYM5ksv31eA99+oJsBX7gPjtxBhFx1KY zm49Ce7CHvD29vKnvpCqBndMEM8xxDKXXVWB/0MxXLxT+077t/iev3yWkm4soiWB8C WLPOSEjhuJodrNGuQvhPRh57hu8ODERjqr9WRP8A= Message-ID: Date: Fri, 23 Sep 2022 16:13:34 +0900 Mime-Version: 1.0 Subject: Re: [PATCH v3] RISC-V: Add Zawrs ISA extension support Content-Language: en-US To: Nelson Chu , Binutils References: <20220918080731.2551374-1-christoph.muellner@vrull.eu> <0dea6e14-323e-64aa-1a61-2574d17e980a@irq.a4lg.com> From: Tsukasa OI In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-6.1 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,SPF_HELO_NONE,SPF_PASS,TXREP autolearn=ham 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 2022/09/23 13:34, Nelson Chu wrote: > On Sun, Sep 18, 2022 at 4:20 PM Tsukasa OI via Binutils > wrote: >> >> Functionally, this is good as is. >> >> For formatting, there is a small room for further improvements (as I >> comment below). This is not your fault but because of my recently >> upstreamed 'Zmmul' patchset. > > The extension orders in the riscv_supported_* tables are not really > important for now. For the single letter standard extensions, the > order is kept in the riscv_ext_canonical_order. All extensions should > be arranged to the correct places by calling riscv_lookup_subset and > riscv_compare_subsets, and all rules of order are mentioned in the > riscv_compare_subsets. So make them in order just for tidy, but won't > break anything. The problem we met for the zmmul is g's imply. The > order in the riscv_implicit_subsets really matters based on the > current implementation, and not sure if we will have another choice to > remove the order limitation when adding implicit extensions. Yep, just for tidying (and I said "functionally" good). And I didn't pointed that 'Zmmul' broke something in that mail. Because 'Zmmul' is upstreamed after his 'Zawrs' PATCH v2 and 'Zmmul' is (supposed to be) placed next to 'Zawrs', it caused extension order different from the canonical ordering while rebasing, that's it. Thanks, Tsukasa p.s. Talking of 'G' -> 'Zmmul' issue I accidentally created... I made a script to prevent that from happening again. It's a hack (sensitive to code formatting) but works perfectly. It checks (A -> B) -> (B -> X) -> (A -> X) for all extensions A, B and X ("->": imply). It reported 'G' -> 'Zmmul' related error just after my 'Zmmul' patchset and reported no errors on the latest master. > > Anyway, the v4 patch looks good and approved, so please commit it when > you think it's time. > > Thanks > Nelson >