From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qt1-x832.google.com (mail-qt1-x832.google.com [IPv6:2607:f8b0:4864:20::832]) by sourceware.org (Postfix) with ESMTPS id 09A7B3858D37 for ; Tue, 16 Apr 2024 20:41:18 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 09A7B3858D37 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=bluespec.com Authentication-Results: sourceware.org; spf=fail smtp.mailfrom=bluespec.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 09A7B3858D37 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=2607:f8b0:4864:20::832 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1713300079; cv=none; b=kew5QSVTBy5f4u6w5JuW+S2ajCEuqVavwcYEQvLQvkFJXPbQp0K08MkfZxEYKtmET+T81jS9zOLO1UYkzcUmlwAqh6EzumuMqDt5jFZ89gIP2DyXRZfshdXSF6VdASYE3fNX9SE0Ei1ionjfHwnKxwTH5kEobDZ+TeLPmC4KITc= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1713300079; c=relaxed/simple; bh=+WPy/NE2jZP/5eP7mbS56Ch/uFXiApv5eju4Vpwu+Cs=; h=DKIM-Signature:Date:From:To:Subject:Message-ID:MIME-Version; b=hFsEVmljW6H6xWyi5V22NVto7Mem3ibawu0HJ8cIMGU81JpyXRc120pONVqz0huja0Bsh6TBUrolxcBRu4OfwNIv7BzejRQFaHnS2LanV3E0Mocmb0icRtH227LH0yS3yCwffzswtbYfTx2OezpdkzRjsHJbjZXL9eOrziZVRsk= ARC-Authentication-Results: i=1; server2.sourceware.org Received: by mail-qt1-x832.google.com with SMTP id d75a77b69052e-437274f3bd4so1470041cf.1 for ; Tue, 16 Apr 2024 13:41:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bluespec-com.20230601.gappssmtp.com; s=20230601; t=1713300077; x=1713904877; darn=sourceware.org; h=in-reply-to:content-disposition:mime-version:references :mail-followup-to:message-id:subject:cc:to:from:date:from:to:cc :subject:date:message-id:reply-to; bh=tdAEuHziZo7Icg6fz5i65oDA0DHLFuq66TepLPsXAxo=; b=ExU9uRF+KJzy+snoPCZJhBwMCZpWyzVJXlhiKsoh+zcrt48h4QKlTfW6JqJtOWZDFv 4i4tlYCsvShSc7HjqS6Xz+h873iMFpu0W7NwXZczILCgfYoc35JJxLjVluIyharF80qc bXjJORY/70Hg5tAk7BlIqHKYNTtFbe41KDMZntDY4IqgfOxJd348AIVBiokQ+HkJvUUt Gx5gFhzRRAXsFH+qdWs9BJcBYHr3BQ0LaNDEZ0PPt7hzhCrE+e147Pi7FpdI89HIn4xi xLVn5JV/xsmwm6Cye6EWR46ZJmtnvGIbG7zhOlMLllPq0MHBp1dZrhD1RGlQdH05hMhf JcFg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1713300077; x=1713904877; h=in-reply-to:content-disposition:mime-version:references :mail-followup-to:message-id:subject:cc:to:from:date :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=tdAEuHziZo7Icg6fz5i65oDA0DHLFuq66TepLPsXAxo=; b=l6qLonprdVCjZVsvyyPDgd3xedmw43jTAm5FR2uNBCqjxRCpd13DDuVa1pqzKr+vTG DMfVFSUyIYYVWRJzm15BgWgc59gyuKO/dwz7O2pXRGcElXlmP84f51y3i7pBoUgxyx49 6pRFq8n5t4i4BqjuDsbiuKGvYHtjRPbNiHLy/XPYuySPqw1MIzi5cOplmbDt/JicXe6s 381LNunlANHyRRBwiwkYn+i8O8oxRpTRGDntf3txV/Fh1iRgW4PSeHE7wQEjxCJ9FK+U AnBXZjTMIQMMmwal6yWitgGkZ068vASRSD4X2NUJAI0kxiUSCX4i6Iop2lJKmBbuE2jC 4YhQ== X-Gm-Message-State: AOJu0YzoEAV0EdmkbprbmbbOR0dLUK/mmmtUaNxhAXGD4aaVsTG23J/r xiWRo8fBTcHjIWO8qB3oSNh+HUVH7eb1y5njID/peQLkQFf1DPbXzjcE+j8aptAQOaH5hlW9/C+ 0 X-Google-Smtp-Source: AGHT+IGwkgwJYu3vscIbz3GFdwwRFqIIXSJ5Bz3TMKLWCGkQ9j5UN0j3G0wRQJ7u7CMbcBfnJo8oQQ== X-Received: by 2002:a05:622a:550:b0:435:a606:878 with SMTP id m16-20020a05622a055000b00435a6060878mr6779824qtx.23.1713300077292; Tue, 16 Apr 2024 13:41:17 -0700 (PDT) Received: from localhost.localdomain ([181.214.94.175]) by smtp.gmail.com with ESMTPSA id h11-20020ac8514b000000b00432bd953506sm7515832qtn.84.2024.04.16.13.41.16 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 16 Apr 2024 13:41:17 -0700 (PDT) Date: Tue, 16 Apr 2024 16:41:15 -0400 From: Darius Rad To: Palmer Dabbelt Cc: libc-alpha@sourceware.org Subject: Re: [RFC] build-many-glibcs: Add a rv64gcbv-on-rv64gc/lp64d sub-variant Message-ID: Mail-Followup-To: Palmer Dabbelt , libc-alpha@sourceware.org References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: X-Spam-Status: No, score=-3.5 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,JMQ_SPF_NEUTRAL,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_NEUTRAL,TXREP autolearn=no 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 Tue, Apr 16, 2024 at 09:04:24AM -0700, Palmer Dabbelt wrote: > On Tue, 16 Apr 2024 07:55:38 PDT (-0700), Darius Rad wrote: > > On Mon, Apr 15, 2024 at 02:36:59PM -0700, Palmer Dabbelt wrote: > > > On Mon, 15 Apr 2024 13:24:14 PDT (-0700), Darius Rad wrote: > > > > Is this really lp64d? > > > > > > I guess that depend on what you mean by "ABI". Passing `-march=rv64gv > > > -mabi=lp64d` will result in binaries that require the V extension to run, > > > but can be linked with any other binary that is compiled with `-mabi=lp64d`. > > > It's essentially the same as `-march=rv64g -mabi=lp64`, except for vector > > > instead of float. > > > > > > > Got it. I thought that might be the case, but wasn't sure if the vector > > calling convention leaked in with the arch switch only (and not the abi). > > The intent was to avoid that, but GCC-14 will be the first release with any > meaningful vector codegen so I guess we'll find out if we have any bugs ;) > > > > > What is the status of the vector ABI? > > > > > > We don't have a global vector ABI switch for GCC (ie, `-mabi=lp64dv`) and we > > > decided not to put on in for GCC-14. We've essentially got all the > > > machinery there for it, as we've got the vector calling convention > > > attribute, but that came in pretty late and we decided it'd be better to > > > wait. > > > > > > I don't see any reason it'd miss GCC-15, but no promises as there's not even > > > a patch on the lists yet... > > > > > > > Understood. Though when this hits, won't it be the most likely target for > > vector? Meaning at that point, rv64gcbv/lp64d would be less useful or > > important. > > I'm not really sure. If I was building a system I'd want an lp64dv-flavored > ABI, but if distros are already rv64gc/lp64d then rv64gcv/lp64d would > provide a binary compatible upgrade path for them. Assuming we end up with > some sort of glibc-hwcaps the rv64gcv/lp64d builds might be common. > > It's kind of all just a guess until HW shows up, though... > > > > > If we need to > > > > have (and test) more targets that are actually useful, so be it. But we > > > > don't want to be stuck testing targets nobody uses or that provide no > > > > testing value, and removing them is usually harder than adding them. > > > > > > Ya, that's kind of my worry here. We'd be going out on a limb here by > > > targeting something without hardware availability, we've already got some > > > baggage floating around from lightly-used targets and it'd be best to avoid > > > too much of that. > > > > > > > Maybe make an explicit note that if/when the vector ABI is in gcc, the > > target will be switched to that, rather than another target being added. > > Then there's some notice for people to not rely on rv64gcbv/lp64d, or at > > least put up support and/or evidence of a use case to retain the target. > > Ya, I guess so far we've not really been explicit about what's supported in > glibc and what's not -- there's some code in there to ban stuff like lv64f > and some default ISAs in build-many-glibcs, but I don't know if any of that > is really binding. > At least build-many-glibcs, and more importantly the release notes, indicate what is actually tested, which says something. > So maybe we should do a wiki entry with what configurations are actively > tested and thus likely to work? > Sure, if we think that can be kept up to date. I think I would rather take an official position on what build-many-glibcs or the release testing means for supported targets (if there isn't something glibc-wide already), then we don't have another thing to maintain. > > > IMO it's really more of a question for users/distros -- and I'm definitely a > > > crazy person on that front, I run Gentoo