From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id aNmTMhU6fmLBCwYAWB0awg (envelope-from ) for ; Fri, 13 May 2022 06:59:33 -0400 Received: by simark.ca (Postfix, from userid 112) id C2D1D1E220; Fri, 13 May 2022 06:59:33 -0400 (EDT) Authentication-Results: simark.ca; dkim=pass (1024-bit key; secure) header.d=sourceware.org header.i=@sourceware.org header.a=rsa-sha256 header.s=default header.b=fO9wA/0Q; 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=-3.0 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,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 12D831E01D for ; Fri, 13 May 2022 06:59:33 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id ED5513839C47 for ; Fri, 13 May 2022 10:59:31 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org ED5513839C47 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1652439572; bh=94ZKSXCM1J8l0zW3j0X+Qfl3qWUtfLnAjgOOUxGQ+y4=; h=To:Subject:References:Date:In-Reply-To:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To:Cc: From; b=fO9wA/0QUQDlCQGUBHQeRAij5FKMt209mD9Y1v3507AOKT0PHs11Y035e1UKfpuG+ +sgBE5j5rLJa46GIQtL65yFXNULxY7y/xnl2WJhz1S3I23YtPn8n+U/4NJrNXM9tbV ztnl0Y+aR5aBcBAEz5dQvm0HTOOI3kXlosGaxSK4= Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by sourceware.org (Postfix) with ESMTPS id 214353857349 for ; Fri, 13 May 2022 10:58:14 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 214353857349 Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-665-i3w1IGAWP2uwYddyNpG4UA-1; Fri, 13 May 2022 06:58:10 -0400 X-MC-Unique: i3w1IGAWP2uwYddyNpG4UA-1 Received: from smtp.corp.redhat.com (int-mx08.intmail.prod.int.rdu2.redhat.com [10.11.54.8]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 4AEE3185A7A4; Fri, 13 May 2022 10:58:10 +0000 (UTC) Received: from oldenburg.str.redhat.com (unknown [10.39.192.147]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 6DD58C44AE2; Fri, 13 May 2022 10:58:08 +0000 (UTC) To: Christoph =?utf-8?Q?M=C3=BCllner?= via Binutils Subject: Re: Supporting RISC-V Vendor Extensions in the GNU Toolchain References: Date: Fri, 13 May 2022 12:58:06 +0200 In-Reply-To: ("Christoph =?utf-8?Q?M=C3=BCllner?= via Binutils"'s message of "Fri, 13 May 2022 12:00:21 +0200") Message-ID: <87y1z5d7i9.fsf@oldenburg.str.redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux) MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.85 on 10.11.54.8 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com 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: , From: Florian Weimer via Gdb-patches Reply-To: Florian Weimer Cc: GNU C Library , Philipp Tomsich , Christoph =?utf-8?Q?M=C3=BCllner?= , GCC Patches , gdb-patches@sourceware.org Errors-To: gdb-patches-bounces+public-inbox=simark.ca@sourceware.org Sender: "Gdb-patches" * 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. Not every useful CPU feature can be adopted through run-time dispatching (IFUNCs, function multi-versionining). Thanks, Florian