From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pj1-x1030.google.com (mail-pj1-x1030.google.com [IPv6:2607:f8b0:4864:20::1030]) by sourceware.org (Postfix) with ESMTPS id 0B64D3858D1E for ; Thu, 7 Sep 2023 16:39:18 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 0B64D3858D1E Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=rivosinc.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=rivosinc.com Received: by mail-pj1-x1030.google.com with SMTP id 98e67ed59e1d1-26d54d3d984so842993a91.1 for ; Thu, 07 Sep 2023 09:39:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rivosinc-com.20230601.gappssmtp.com; s=20230601; t=1694104757; x=1694709557; darn=sourceware.org; h=content-transfer-encoding:mime-version:message-id:to:from:cc :in-reply-to:subject:date:from:to:cc:subject:date:message-id :reply-to; bh=S0RYQWEfJxJC4fK28JD5MA/9WiiW6hVvHf/mwTml27A=; b=MjndFyH3ZUNIRBEU6lxyBWtyTuc5dm6+YHckf4KLga+LnjckXg3WbdVJyorSt9fBN3 gf4TSgc35R7YGcCwj4qMzNJNXfKAZsOHy1ee38MYtWIC4t9FIJ7bLnwxqD00vXMcSo7n Jt9e0eMBiFzCAqqnB5FIgDHNGgeL6WMhxCy6A8jvYNsEJi+uRmkeAIG5nz7b/GAi0xYz l70NgMYvWT8yjxvq1GtLXjNH+salSR2Dz7SM3QFa4gYy6+8J4q3aducOZtBVq2BkWkM7 6z6+sPvOYzjRsj5f6BfO07GFeiF89MxPA/0S2uhID3soRhfPk7uEBvJRy9RiA8ms64HN J0YA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1694104757; x=1694709557; h=content-transfer-encoding:mime-version:message-id:to:from:cc :in-reply-to:subject:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=S0RYQWEfJxJC4fK28JD5MA/9WiiW6hVvHf/mwTml27A=; b=EUyj7DCUwd9hDD5CSQDcTacwOAjTsnNZGZbpBBDq5u6EyiDi7YFPxNCYFTD8qc516N ADyEGNwYSW8Tb42AGmY+QuLIyQTwKg3FtYazeu7idMYAX4mwTxg6bazAu/6gnTtl7OPT LCtevG2oCLqT0qLU9t5qqB3DajyXYGtUldD8hJMf5SJFgmXftwQ3LAqVuHTyNw6wbFxj feVRfpM/if5GdJt7oZRVFEdGnrtdEJZcl2GTKPgeKtcA/UwCbMCYtA9uWnISGEg//CkS ShHQpsYjvJaCT4J8OZo8HedngrF6HZLfuuIES/OhCqBOkHQpNhJ/MpF33N/SlhjFTYVk RlHg== X-Gm-Message-State: AOJu0Yys1zwuxbwTK8kFyWJR38RNKzz2eUNwQwzNqO2F94Ml1JWGfsgI Ur8mk2bUA3fjdI1sZriw/77kYQ== X-Google-Smtp-Source: AGHT+IFFdnCNVNiyY2BQm6uE37xS2qbSpk3lbEn7FWEoaUq6DM/XPPalsSjlOtLmAaikaF2iVaipig== X-Received: by 2002:a17:90a:4ce4:b0:263:1f1c:ef4d with SMTP id k91-20020a17090a4ce400b002631f1cef4dmr164062pjh.10.1694104757055; Thu, 07 Sep 2023 09:39:17 -0700 (PDT) Received: from localhost ([135.180.227.0]) by smtp.gmail.com with ESMTPSA id l15-20020a17090a070f00b002739282db53sm1782102pjl.32.2023.09.07.09.39.14 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 07 Sep 2023 09:39:14 -0700 (PDT) Date: Thu, 07 Sep 2023 09:39:14 -0700 (PDT) X-Google-Original-Date: Thu, 07 Sep 2023 09:39:13 PDT (-0700) Subject: Re: [PATCH] build-many-glibcs: Add a RISC-V config with most of the B extensions In-Reply-To: <87a5ty9e3q.fsf@oldenburg.str.redhat.com> CC: Jeff Law , libc-alpha@sourceware.org From: Palmer Dabbelt To: fweimer@redhat.com, Evan Green Message-ID: Mime-Version: 1.0 (MHng) Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-3.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,RCVD_IN_DNSWL_NONE,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 Thu, 07 Sep 2023 08:50:49 PDT (-0700), fweimer@redhat.com wrote: > * Palmer Dabbelt: > >> On Wed, 06 Sep 2023 13:43:08 PDT (-0700), fweimer@redhat.com wrote: >>> * Palmer Dabbelt: >>> >>>> + self.add_config(arch='riscv64', >>>> + os_name='linux-gnu', >>>> + variant='rv64imafdcb-lp64d', >>>> + gcc_cfg=['--with-arch=rv64imafdc_zba_zbb_zbs', '--with-abi=lp64d', >>>> + '--disable-multilib']) >>> >>> I doubt we need a separate GCC configuration, you should be able to use >>> the existing compiler for that and just change the glibc build flags. >> >> Right now we're building a different GCC for each target, setting the >> default arch at GCC configure time. I agree that's super inefficient, >> but it's what the other tagets do. Sharing GCCs will also result in >> mixing up things like libgcc, which is kind of a double-edged sword. > > It's more mixed, see the power4 variant of powerpc-linux-gnu for an > example. If I'm reading the script correctly, the power4 build is using the same GCC as the powerpc64 hardfloat build? ie this one self.add_config(arch='powerpc64', os_name='linux-gnu', gcc_cfg=['--disable-multilib', '--enable-secureplt']) I think we could do that for this configuration (reuse the rv64gc toolchain), we'd just end up with the libgcc cross-linking issues (which might even be a good thing, as distros will probably have rv64gc libgcc). IIUC we'd need multilib support to get us down to a single GCC build, though. >>> I expect we need some sort of version check because these flags are >>> rather recent, right? To what extend do they actually impact code >>> generation for glibc? >> >> We've got two inline asm routines that use the B extensions (both Zbb): >> >> sysdeps/riscv/string-fza.h:#if defined __riscv_zbb || defined __riscv_xtheadbb >> sysdeps/riscv/string-fzi.h:#if defined __riscv_zbb || defined __riscv_xtheadbb >> >> That's a pretty small diff, but it is code we're not testing -- not >> sure if that's worth a whole test config, though. > > You can add IFUNCs and compile the affected string functions twice, then > code *will* be compiled in a default build, revealing syntax and other > errors. +Evan, who's working on the IFUNC support. I hadn't though of using that to test the assembly, but that seems like the best way to go -- not only will it sort out the testing issues, but users will go faster ;) I think we're pretty close? >> On the compiler side the B extensions have a pretty big impact on >> codegen: they add a bunch of common bit manipulation patterns >> (sign/zero extension, bit fields, C strings, etc). None of that >> should change the ABI, so in theory we should be safe if the GCC test >> suite passes. We do glibc builds as part of the GCC testing, but that >> usually targets released glibc versions so stuff might slip through. > > Do the B extensions change the relocation footprint because they add new > instruction encodes? That's an area where we've sometimes encountered > problems with changes in ISA baselines/compiler flags. We don't have any new relocations for B, at least not yet -- they're all just register/register ops, so while one could imagine some addressing patterns that take advantage we don't have them yet. So I think we're safe on that front. > > Thanks, > Florian