From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id BnaqGzJAfmKzDAYAWB0awg (envelope-from ) for ; Fri, 13 May 2022 07:25:38 -0400 Received: by simark.ca (Postfix, from userid 112) id 609A61E220; Fri, 13 May 2022 07:25:38 -0400 (EDT) Authentication-Results: simark.ca; dkim=fail reason="signature verification failed" (2048-bit key; unprotected) header.d=vrull.eu header.i=@vrull.eu header.a=rsa-sha256 header.s=google header.b=GwKC2cLw; dkim-atps=neutral X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,MAILING_LIST_MULTI,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.6 Received: from sourceware.org (server2.sourceware.org [8.43.85.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPS id 0BD4B1E01D for ; Fri, 13 May 2022 07:25:37 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id A150B3881875 for ; Fri, 13 May 2022 11:25:36 +0000 (GMT) Received: from mail-wr1-x42f.google.com (mail-wr1-x42f.google.com [IPv6:2a00:1450:4864:20::42f]) by sourceware.org (Postfix) with ESMTPS id BFE9E384F01F for ; Fri, 13 May 2022 11:25:01 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org BFE9E384F01F 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-x42f.google.com with SMTP id t6so11037986wra.4 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=Au+E3LZromafvhfOTCpo0jiz4lgULbt62MXjpAWqGnrRhYYaGdKaBUZKAZ5u77LHyf Hh10qLi85sVKNBMWjCgNLGyNDZK2kkyPAeMthIzeWvgmYcm/9FtEOBnThPmh8WgK0mDm yB+rJZSn3sydbl+lQRfGxcscmy+jWsmAjctoNv5hL/yqIuGrb4IFuoecdIZrKDsAGpMj yJubWhkmm16WHM6ZUnGSXZRD5Ye2lCuboBf4MyemLPqLjw9st57oIUuqbQsFN8tsdgRH EyGmUq9+hYE6PGwM/nNRyqZLvdvq3p6oEPdgMK9DQSqg5xg3v5L1c5m+bl9tSwdLKcmp e8Ow== X-Gm-Message-State: AOAM532Iykcny+hzt7dUAq8JglVOc7A47sBpp9Scnu8kVthEpHa+tisJ m8Ryx7NJMpX7E0X3Dt14k0ubfTTkvL/32h/ng9g+hg== 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 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: GNU C Library , =?UTF-8?Q?Christoph_M=C3=BCllner?= , =?UTF-8?Q?Christoph_M=C3=BCllner_via_Binutils?= , GCC Patches , gdb-patches@sourceware.org Errors-To: gdb-patches-bounces+public-inbox=simark.ca@sourceware.org Sender: "Gdb-patches" 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.