From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pl1-x632.google.com (mail-pl1-x632.google.com [IPv6:2607:f8b0:4864:20::632]) by sourceware.org (Postfix) with ESMTPS id 33745385B53C for ; Thu, 7 Sep 2023 15:24:36 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 33745385B53C 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-pl1-x632.google.com with SMTP id d9443c01a7336-1c0c6d4d650so8929165ad.0 for ; Thu, 07 Sep 2023 08:24:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rivosinc-com.20230601.gappssmtp.com; s=20230601; t=1694100275; x=1694705075; 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=Ftyka/u3xZ5x2jRFfmnu9J9v2j1BooezFWpKaJa7HN0=; b=ZIIJU7Fu4G727GQPyc6n+H0syeV+v/chj9p1ExasDRvxNDf3qS9yRBFGlFF8v8KEQW F7w7evGWL5LIYVcLdJn8uGcm9I4NPXCcmBpAEwlyyULZkTuIyA75t3YTs4WxUde+06HS Ewdh0T8jZNbdFFfenv6t5oCwDRCeLZIMR2fzlUChpd9OnyUMwJOpWevTKpwU0aJoiJP9 A3Y5RHRAOyxc8G4Gz4Zjdz+B45Uu78hIXvpa/J+XDbX0ASVquTH8Ax9JsQIxUEpqoYD/ j0hMbi7orvnu4HPJ+0KTHR1gZasXxhto2MWph8qpL8riW9uLa8eW5y1k+UKsjs4TvUv1 /lKg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1694100275; x=1694705075; 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=Ftyka/u3xZ5x2jRFfmnu9J9v2j1BooezFWpKaJa7HN0=; b=PcXF08cOjlVVtkrvg/8vKtYj5XNGKGaC1Pk0eN/C1KszcERu/Tz45o+tErXwbOcTIT vvTa5GAs6nl3Spu2UBaxaUaUEMQ8uCsij8Jwnfil1RRyLt2TlPtzDLjfeOv/H+k7cPy0 HiRQkPSpBG9TUQoNdK4PlHPz2z/E740+bsvHLcij5GrMXKlZVohwgQ8eK8xE3GP3SzGc +6HvcBgUY95SbxRhagnQT4DN+FUVWK7Zq630EAQ385AIKqMxgDBZ2M4McnOQ796ifcKt K8qkzYldueYHarFSyLb3i22jpNeRZoCrLlmner+VPlC66w6BqlA9dkhy2cIvh9BtC6LW af2g== X-Gm-Message-State: AOJu0YxXKijAzV0Vvfugf/zLcA82Yvp0Q/mLt/n6huYWhgHv3PIPBCIy TsbYGHPyu2EBpCdE/qp+4u0fPRWQcxEIdiKat8I= X-Google-Smtp-Source: AGHT+IEEK4PSSGRC4M05qvdZB0HCp84Zt3m2FFIYmLWcnDaVO0aqcj2Ck73G4+lClWXVhucyhxuEEw== X-Received: by 2002:a17:902:d88d:b0:1bb:9c45:130f with SMTP id b13-20020a170902d88d00b001bb9c45130fmr6761602plz.69.1694100274765; Thu, 07 Sep 2023 08:24:34 -0700 (PDT) Received: from localhost ([135.180.227.0]) by smtp.gmail.com with ESMTPSA id f17-20020a170902ce9100b001bdc66478c1sm12875550plg.309.2023.09.07.08.24.34 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 07 Sep 2023 08:24:34 -0700 (PDT) Date: Thu, 07 Sep 2023 08:24:34 -0700 (PDT) X-Google-Original-Date: Thu, 07 Sep 2023 08:24:08 PDT (-0700) Subject: Re: [PATCH] build-many-glibcs: Add a RISC-V config with most of the B extensions In-Reply-To: <87pm2vxcbn.fsf@oldenburg.str.redhat.com> CC: libc-alpha@sourceware.org From: Palmer Dabbelt To: fweimer@redhat.com, jlaw@ventanamicro.com 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=-4.1 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 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. I'm not sure what the right answer is here. For the GCC CI we're trending towards a single target that contains most of the new extensions, maybe that's the right thing to do for glibc as well? It's looking like there'll be a generation of hardware that has B but doesn't have V, though, which is sort of what this target is aimed at. Also +Jeff, in case he has an opinion. > 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. 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. So I guess again kind of a grey area. > > Thanks, > Florian