From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lf1-x134.google.com (mail-lf1-x134.google.com [IPv6:2a00:1450:4864:20::134]) by sourceware.org (Postfix) with ESMTPS id 11F693857C45 for ; Thu, 7 Sep 2023 17:01:25 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 11F693857C45 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-lf1-x134.google.com with SMTP id 2adb3069b0e04-500c37d479aso1892310e87.2 for ; Thu, 07 Sep 2023 10:01:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rivosinc-com.20230601.gappssmtp.com; s=20230601; t=1694106083; x=1694710883; darn=sourceware.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=oUN0i+CYE6q8rPQCWdbRuQ+K3FY9DhK+Kxi7rFAMq3E=; b=E+r2oJZR09wQ7BtfkkQRibV40kVUHNfEseo2tu0MML2vkCDCMg3eTT5Ln2RgFM+MbD 1GuVJSHsc8ruODh8k8ehWHz8U2DospBycyeWzHbvTc+Ox2eqYAq+/S4L5SOofsHuBhho TccGd03yS9rpDjEjHJXwEp2NvhQsBg+Jf3wh05DICbYJWHwBBu051Uo/rQJfE3aGlQvZ QBs2C8KeihfMJYp1vN8PNR6l2oBD8urfyOiY7bNGoghV5damr4WdrcYl+YCT5aONyCGd 7HR7PncCc+/XXhyita/rCVTXbrq9P/WzVyGZJwvHwMvpVTnYOX/UuJs94qYcWsQxopTe iRIA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1694106083; x=1694710883; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=oUN0i+CYE6q8rPQCWdbRuQ+K3FY9DhK+Kxi7rFAMq3E=; b=T/cxVe2rqO4VRKbYXnM6nHBhfCoCAQ3NDLXxaoKxzQpdHzXL/N5BriFFwCWwszFeoh H0zYvYqGzRv5P8FVQ1qOLi+53EQtPBujEUYsgNrGVcYZnSOIFKTNcVXau8vxHZFkWFOG y4a7eEH2amV0ge4SFQtck2L25oESe+eiIKvF2AEQxM9cRwI25yno9/4Q+W6UNOXrblO5 HG3uHt69pVMGp58KooX1oCC22w/XOc1XKR3D01PkzXgbiqqxqLnZPkhxVxE7T4Bo6Z+t j1kCU5mN+SpItw8mt9KKGo21MNjmZ/8I+WmAWynIDMCPe9oMqbFbo2/eLoQo2QCFEVw1 C1QQ== X-Gm-Message-State: AOJu0YwKkVTWePaTzFkQBoCgzcGsOxbWK/iGk1nzmPy9l60Zcpdy6VW7 QBzleFFAxbrwYXvPHTEgru8sbXwEA2MnqlN/oPKOiX7M+YfuxaF9 X-Google-Smtp-Source: AGHT+IFLbm71oubQJdHyhgjJ7AiWaS/Phxfw4FcgJzKvOwiDW1f4XgyO4SDO+w9ic6zRw/2n6PXw0YtyCXbGGZcecNE= X-Received: by 2002:a19:770b:0:b0:4fe:7dcb:4150 with SMTP id s11-20020a19770b000000b004fe7dcb4150mr10438lfc.67.1694106083213; Thu, 07 Sep 2023 10:01:23 -0700 (PDT) MIME-Version: 1.0 References: <87a5ty9e3q.fsf@oldenburg.str.redhat.com> In-Reply-To: From: Evan Green Date: Thu, 7 Sep 2023 10:00:47 -0700 Message-ID: Subject: Re: [PATCH] build-many-glibcs: Add a RISC-V config with most of the B extensions To: Palmer Dabbelt Cc: fweimer@redhat.com, Jeff Law , libc-alpha@sourceware.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-3.2 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, Sep 7, 2023 at 9:39=E2=80=AFAM Palmer Dabbelt = wrote: > > 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=3D'riscv64', > >>>> + os_name=3D'linux-gnu', > >>>> + variant=3D'rv64imafdcb-lp64d', > >>>> + gcc_cfg=3D['--with-arch=3Drv64imafdc_zba_zb= b_zbs', '--with-abi=3Dlp64d', > >>>> + '--disable-multilib']) > >>> > >>> I doubt we need a separate GCC configuration, you should be able to u= se > >>> 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=3D'powerpc64', > os_name=3D'linux-gnu', > gcc_cfg=3D['--disable-multilib', '--enable-secure= plt']) > > 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, the= n > > 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? I hope so! No one's got any corrections yet on my v8, so we'll see. I haven't dug through this thread, so I'm coming in with only the trimmed context of what was in my inbox. Won't using ifuncs end up being a fairly big runtime penalty, since you're changing "static __always_inline" functions into calls through a pointer? Or is the idea something like: create two files just for test, like string-fzi-zbb.c, and string-fzi-nozbb.c that each force the __riscv_zbb one way, and each define non-inline functions like index_first_with_zbb() that turn around and use the inline ones. Then another just-for-test file with an ifunc selector between index_first_with_zbb() and index_first_no_zbb(). Then you exercise the ifunced index_first_for_test() in test code? -Evan > > >> 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 ne= w > > 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