From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pl1-x62b.google.com (mail-pl1-x62b.google.com [IPv6:2607:f8b0:4864:20::62b]) by sourceware.org (Postfix) with ESMTPS id C15FA385842D for ; Tue, 30 Apr 2024 16:26:31 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org C15FA385842D Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=dabbelt.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=dabbelt.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org C15FA385842D Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=2607:f8b0:4864:20::62b ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1714494394; cv=none; b=FkvDU4Fi4hftWYnfU3jySBBsxmb8/o7+eirULcxWDIQjvXCiStv5soq6Xb+fDrEyZXzJYNwSg5bCbM0ysmHF5JdcG6V84emJZZFKUUf/zkNFqrQs2S0qcMoHJ1ofi7LhqCYewGQYfmMT1BjdPeKF0CTNp+yWX9ocsA3thdSmTRU= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1714494394; c=relaxed/simple; bh=y/es36qLKBolJaDuLHOBiSKBxDtyE+k9JK62sJze04Q=; h=DKIM-Signature:Date:Subject:From:To:Message-ID:Mime-Version; b=qiFoj8Q8y2UnclNaogh3/8dM1MpXgYmSR56OsQeVf21NEjpp+ClIq2MYfjMz1sKqODC3oaE+/GNvLyBd3bImg+/yZBaI0scoDuM4/a50EqtPeviyMQI9J6JutOYVCzLTfTFasocDKdz8Vp+REw3DJVrjyIiKGo9i3GXfVnxm8L8= ARC-Authentication-Results: i=1; server2.sourceware.org Received: by mail-pl1-x62b.google.com with SMTP id d9443c01a7336-1e65a1370b7so55237205ad.3 for ; Tue, 30 Apr 2024 09:26:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dabbelt-com.20230601.gappssmtp.com; s=20230601; t=1714494391; x=1715099191; 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=RhqZmIcFpnS96EyTWVOSE0GsaB7hqFRJh6ekqDTMYc8=; b=QTRJPGGmt8HhOfmI82lSUcEq5GJVME917hpsjv5zR/ajvHBDTdvTe8/zZWPFGA/QVP HAijtxmjm4aagHxC54ODC3W85JM1Y9jaYCcEQD/2toGa5JwtzD3EPvx+wnxwOadbrxvM m+BjAtH3Mzzjq822DS7zNQT+qfq/MkCc7TqDfjUKQLV33lfd/IxIJxdsK1IfvyaScrB/ TQjp8/UkPl2SHU0PKvPhC/WYGRedOC4W3gmiI554Qq06tfVFnOS53vASkrMgK2yuOucP 1DxAr3bUVsl+1aFftvs9pVB8GE88cu0npQMzyIQUjFKR0OktQJoLW/H8k2VhR5HL+FOx MrQw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1714494391; x=1715099191; 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=RhqZmIcFpnS96EyTWVOSE0GsaB7hqFRJh6ekqDTMYc8=; b=GE8E94fizbkQo4ePD/YBgMwVZUqf/puPXtpIzBQFfsSzNauvFt1UMu/yR6/0Ln0yXc CPl/WREwmXjfLEoGTwmpUAIq4j8atg8U3XCXRmsr12VD+dam8ConGy9LNsJa6/m9UByg ByUr2TaM8qaukEpACjOFLWRhBT/8SL1ObmAzSLHH4LzJ0/tgbD5/ZKFrFzAX1EnbJxtx aNl3dFrC5COnBESEmBwrLGy3dOYz77Zt3GN/8VkCPIR8Q9FtbdLV6olrDCweW/A481aE dGdgNkflDzQWkdrLMZGjL4ppoSwv5f4OlkbLHxFI6MIG6Yri95mgex4QONfODquy3EOq f0TQ== X-Forwarded-Encrypted: i=1; AJvYcCXr3bkd6WoTUZfpvLNR+GjgJaN44wnDMUUNfHfzHXec4b6EcPc9p4tnARjTRepU6zWdaCHNsn2mGqKIsgpbLEyFHzQmC4r7bD5V X-Gm-Message-State: AOJu0YwVZDFtY6apMlTH1xowkDtdDRhH71AcononlLJTwS2IX9vzLV4f SM8gfwUOyix3nDKGf3KBeQ5MBk9kqcKMWOu1SAJi6u1xcfYU5Wa1LqCDe478St4= X-Google-Smtp-Source: AGHT+IEUiuTPAW2LhAulXktUnVpaHANZwbI+gCt+fKf1YTusa8tmFkKS9KFRRCOp8KEgDPnpda6fRw== X-Received: by 2002:a17:902:ec91:b0:1dd:e114:121c with SMTP id x17-20020a170902ec9100b001dde114121cmr23329568plg.56.1714494390374; Tue, 30 Apr 2024 09:26:30 -0700 (PDT) Received: from localhost ([50.145.13.30]) by smtp.gmail.com with ESMTPSA id s15-20020a170902ea0f00b001ddc83fda95sm22573470plg.186.2024.04.30.09.26.29 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 30 Apr 2024 09:26:29 -0700 (PDT) Date: Tue, 30 Apr 2024 09:26:29 -0700 (PDT) X-Google-Original-Date: Tue, 30 Apr 2024 09:26:23 PDT (-0700) Subject: Re: [RFC V4] Enable libmvec support for RISC-V In-Reply-To: CC: shiyulong@iscas.ac.cn, libc-alpha@sourceware.org, Darius Rad , Andrew Waterman , maskray@google.com, kito.cheng@sifive.com, wuwei2016@iscas.ac.cn, jiawei@iscas.ac.cn, shihua@iscas.ac.cn, chenyixuan@iscas.ac.cn From: Palmer Dabbelt To: jeffreyalaw@gmail.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.0 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, 24 Apr 2024 22:07:31 PDT (-0700), jeffreyalaw@gmail.com wrote: > > > On 4/15/24 1:21 AM, shiyulong@iscas.ac.cn wrote: >> From: yulong >> >> Diff: Chande the version from GLIBC_2.39 to GLIBC_2.40. >> This patch tries to enable libmvec on RISC-V. I also have demonstrated >> how this all fits together by adding implementations for vector cos. >> This patch is a try and we hope to receive valuable comments. > Just an FYI -- Palmer's team over at Rivos have implementations for a > number of routines that would fit into libmvec. You might reach out to > Ping Tak Peter Tang for information in his > implementation. > >> https://github.com/rivosinc/veclibm/ > > > THeir implementations may provide good guidance on performant > implementations of various routines that libmvec typically provides. Ya, that's the idea of veclibm. The actual functions are written in a way that's more suitable for some other libraries, but the core computational implemenations should be the same. A few of us had briefly talked internally about getting these into glibc, IIUC all the code was written at Rivos and thus could be copyright assigned to the FSF and used in glibc. We don't have time to do that right now, but if you're interested in helping that'd be awesome. We'll need to be careful with the copyright/licensing, though. That said, I've never really quite managed to figure out how all the libmvec stuff is supposed to fit together. I'm more worried about the ABI side of things than the implementation, so I think starting with just one function to get the ABI template figure out is a reasonable way to go and we can get the rest of the implementations ported over next. The first thing that jumps out on the ABI side of things is cos() taking EMUL=2 types, I'm not sure if there's a reason for that but it seems we'd want EMUL=1 to fit more data in the argument registers? Also, I think some of this can be split out: the roundtoint/converttoint isn't really a libmvec thing (see https://inbox.sourceware.org/libc-alpha/20220803174258.4235-1-palmer@rivosinc.com/, which fails some test), and ptr_barrier() can probably be pulled out to something generic as it's the same as arm64's version. I'm also only seeing draft versions of the vector intrinsics. I know we merged them into GCC and usually that means things are stable, but we merged these pre-freeze (based on some assertions things wouldn't change) and things have drifted around a bit it the spec. I think we're probably safe just depending on the types, if there's no frozen version we should at least write down exactly which version we're following though. Also: are there GCC patches for these? It'd be great to be able to test things through the whole codegen stack so we can make sure it works. > > jeff