From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr1-x434.google.com (mail-wr1-x434.google.com [IPv6:2a00:1450:4864:20::434]) by sourceware.org (Postfix) with ESMTPS id CBB42384F021 for ; Fri, 13 May 2022 11:25:01 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org CBB42384F021 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=vrull.eu Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=vrull.eu Received: by mail-wr1-x434.google.com with SMTP id u3so11050181wrg.3 for ; Fri, 13 May 2022 04:25:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vrull.eu; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=nhvK+2G+fCOHmacfe3gaezFW8cQVe6/asLEJqx6CP04=; b=GwKC2cLw3eGpTkHARadS85oJOHSeJoLOUursGPTylF2ZLj2LSMw5tC7wMh3vga45y2 UDkCIV7nnLJmliZK9IoxrkqSJMDcK2/iJ3P/0kKfLRD/h+nbZsGdIfdZP98Mio0XauEE sBDLKNfyGypFfsn7yzwVjpNaMpyU8ymolqVxZ+ET28eJffnagxDxn1iFbgav3E8SrSPt /MfOUwuAusUxm6YFTm7nTOw+87tXW2SqiaFQ7JirxZLVT+eCcUEtK7n4EWFwjtUyAj7c diojyeMPR6XnFjbhCwdq4/xgNUtdQ7pX5ZsQv1vEvxVpGc0gmM6NvXIsgwTa1/clMNVs ISLw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=nhvK+2G+fCOHmacfe3gaezFW8cQVe6/asLEJqx6CP04=; b=jSdWLcDbbUCxOBeBrRjUEtHQY0roR0qe2zSN75lTh52TpnqrklqVymqBk+O6HVxuy+ r2LNSoAAYcNwdlkEPX5PPJMPIB9XjzUuiqx6xigd3ZUOFhxh6uIA/ELVZ9LvQYVecCYi KQfXtNSMOG8Ya8alR2C2snc6pqKyTJltl9v2wb9zSty4jugtVN3+4GMSpUJebaNP/RQZ 76XKhm5eyaPT96VJBvljewuOIgEtpVsDivAVPGhPjtiB+b7XwIKm+nb2R/A0mmN8yUTC fvmNhcgC7Jj2BUeVHKOFluy66RO7dz/N0CL9mvUdiugl2EdMf6hwwjSZ8tL1fWSfX9Oj NEyg== X-Gm-Message-State: AOAM531xoejEwsw6x3KMaRuEwhBF4jZmwoDYW1jIT97WGnA+C7k7OPMU 349XAvz5zCvIRxH/jre9J5H4cKRPGfGNAyvFU1q8G1Hk/yNsRI/A X-Google-Smtp-Source: ABdhPJwZT4YBhDUqKZzS++G+pFiDrFLqdgvfIddiflzSxruj0AAi4zCY/p7bJcPMBnCy7ZWZuAcSZ5ENzjappIu4gnE= X-Received: by 2002:a5d:54c4:0:b0:20a:d2ea:1f7f with SMTP id x4-20020a5d54c4000000b0020ad2ea1f7fmr3497383wrv.306.1652441100601; Fri, 13 May 2022 04:25:00 -0700 (PDT) MIME-Version: 1.0 References: <87y1z5d7i9.fsf@oldenburg.str.redhat.com> In-Reply-To: <87y1z5d7i9.fsf@oldenburg.str.redhat.com> From: Philipp Tomsich Date: Fri, 13 May 2022 13:24:49 +0200 Message-ID: Subject: Re: Supporting RISC-V Vendor Extensions in the GNU Toolchain To: Florian Weimer Cc: =?UTF-8?Q?Christoph_M=C3=BCllner_via_Binutils?= , Palmer Dabbelt , =?UTF-8?Q?Christoph_M=C3=BCllner?= , GNU C Library , GCC Patches , gdb-patches@sourceware.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-3.6 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, JMQ_SPF_NEUTRAL, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, 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 X-BeenThere: binutils@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Binutils mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 May 2022 11:25:03 -0000 On Fri, 13 May 2022 at 12:58, Florian Weimer wrote: > > * Christoph M=C3=BCllner via Binutils: > > > I'd like to add two points to this topic and raise two questions. > > > > 1) Accepting vendor extensions =3D avoidance of fragmentation > > > > RISC-V implementors are actively encouraged to implement their > > own ISA extensions. To avoid fragmentation in the SW ecosystem > > (every vendor maintains a fork of tools, distros and binaries) there > > needs to be a principle acceptance to get vendor extension support > > upstream. > > If you eventually want portable binaries, it's necessary to converge on > a small set of widely implemented extensions. x86 didn't have this, and > adoption was poor outside specialized libraries (and JIT, of course). > Yet everything was as upstream as possible (ISA manuals, assemblers, > compiler intrinsics, even automated adoption by optimizers). So > upstreaming is only the first step. Some of the earlier discussion seems to have mixed two different goals: 1. making the vendor-defined features available to the developer and ensuring that no unintended consequences (e.g., "accidental" interlinking) happen, so developers can choose to adopt them (e.g. through dynamic detection) where appropriate; 2. having widespread adoption for features across libraries/applications that take advantage of all implemented features As this is cross-posted to projects that provide the infrastructure, tools, and plumbing, we should IMO focus on goal #1. Coming from the RISC-V ISA philosophy, this also makes excellent sense: after all, RISC-V is (in its purest form) an "ISA construction kit": one can add extensions or leave extensions off. For the essential development tools, this flexibility is reflected in the myriad of combinations that "-march" can have (just consider that there are 4 distinct Zb[abcs] extensions that add addressing, basic bit-manipulation, carryless multiplication, and single-bit operations=E2=80=A6). If individual downstream users see benefits from any= of these (e.g., Zbb for strlen; Zbc for GHASH, =E2=80=A6), they will contribut= e optimized code-paths under ifunc (or whatever other mechanism a given library/application uses); however: we first need to have our tools support these extensions (both standard and vendor-defined) and ensure that no accidental interlinking happens. Finally, to enable binary distributions, a basic architecture level that everyone agrees on (these are being defined at the RISC-V Foundation under the "Profiles" and "Platforms" umbrellas) provides a baseline to target that will provide some level of "runs everywhere" based on such a "small set of widely implemented extensions". Philipp.