From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pj1-x1036.google.com (mail-pj1-x1036.google.com [IPv6:2607:f8b0:4864:20::1036]) by sourceware.org (Postfix) with ESMTPS id 673943858D1E for ; Thu, 7 Sep 2023 17:05:15 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 673943858D1E 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-x1036.google.com with SMTP id 98e67ed59e1d1-26d0d376ec7so910473a91.2 for ; Thu, 07 Sep 2023 10:05:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rivosinc-com.20230601.gappssmtp.com; s=20230601; t=1694106314; x=1694711114; 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=3+pWxXyDLCeojD+7lb91kqOCV5ngVPR0l/3indNfMcI=; b=UCeGy39FxmH2vaPMvbp5Sm+TiVOXmEZedMzzFtvNvxcMIAGdGAeIlxiDNEW2DfNi34 Vm3omf0wrAwv6HxdgGcgtxH3eCKpA4+n9sQEg6AqjTkyH7tSbw8CNKxaQ4S5lcR/EdAw KcSlb5fYPDCbCIAIA7eiG0PbqEs4cTfbAKPBNlH9M85t63RkgcC97cOSy/OLVZ88QHjm HHqg2n01erXvtzwDKo2fzEgCFNVJT6XRGyuAPjQec129phrbuJgjnQG9fyrsD18VGRn5 xsuTSXgwNJwxXcBD+KrMSA7xNk6mn/vx9IsXjru9Cn1oJlw+eAwjzR705JzpsbfcNuCR MhLA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1694106314; x=1694711114; 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=3+pWxXyDLCeojD+7lb91kqOCV5ngVPR0l/3indNfMcI=; b=j/pJCyhBMlqWqMpklbpd2OXdZpie7D0Tp2+JQAX83jAwu+MUcZKBvk64aafWXzLjlW g/v46JSk0rsSSK6zIG1+Xf5vIREy9QUQ2OlWekEX4S1v4dcZ5VlCJUxvS6jFJRGwXHCN vY2uv72G4kZW1mqI4clzrxEq/kt8NiZc6OEKzjm7y3kn2x4PvQWritOiHea812ixUSR0 nf6PXl6bzEUGsmGXcn4XK/u8+/zoZ1pPFedFym+9AXkS4685uGWTZqB+s4vihtr0RFMA 1tVjeVfWnl7dPrZs9z6nqFYFEqzyxXpNhA4I8RxFtot8UTzA0PnQ33xg/qGls9EWj79L Cp3w== X-Gm-Message-State: AOJu0Yxbv7urIFxQSWd5OR3MeebHWCGgy9LAUr2+gaWI6C6y85Aaiwu6 m/9sTvsLdREAQsehjbzgoTooPbiEU8HxavTcEnA= X-Google-Smtp-Source: AGHT+IE1OT1sgMJ1a07UhFI1EVhe7EWOw1T/F2/bpVIwF+ap0AAHMZ+tF5htX3cXGwd20cEaA8p8eQ== X-Received: by 2002:a17:90b:203:b0:25e:a8ab:9157 with SMTP id fy3-20020a17090b020300b0025ea8ab9157mr202998pjb.22.1694106314261; Thu, 07 Sep 2023 10:05:14 -0700 (PDT) Received: from localhost ([135.180.227.0]) by smtp.gmail.com with ESMTPSA id pc16-20020a17090b3b9000b00268dac826d4sm1687570pjb.0.2023.09.07.10.05.13 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 07 Sep 2023 10:05:13 -0700 (PDT) Date: Thu, 07 Sep 2023 10:05:13 -0700 (PDT) X-Google-Original-Date: Thu, 07 Sep 2023 10:05:11 PDT (-0700) Subject: Re: [PATCH] build-many-glibcs: Add a RISC-V config with most of the B extensions In-Reply-To: CC: fweimer@redhat.com, Jeff Law , libc-alpha@sourceware.org From: Palmer Dabbelt To: 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.5 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 10:00:47 PDT (-0700), Evan Green wrote: > On Thu, Sep 7, 2023 at 9:39 AM 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='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? > > 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? I think we'll just have to IFUNC the uses of these functions, looks like it's all in the string ops. > 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 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