From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pf1-x432.google.com (mail-pf1-x432.google.com [IPv6:2607:f8b0:4864:20::432]) by sourceware.org (Postfix) with ESMTPS id F09FC394800A for ; Wed, 1 Feb 2023 17:07:41 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org F09FC394800A Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-pf1-x432.google.com with SMTP id t17so1758570pfj.0 for ; Wed, 01 Feb 2023 09:07:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=KEt5bCt4+kvFUYWh9A52JkpIaQ1BI8sVOrn4yplbLyM=; b=euQOVj0MCwcn60zV4+2ipevT/a0NTVgTRDC23PYcCuWYm8nb3e4ynPBsOLhiYYCJ+4 s9uDNSAX6OEwD6qcku+iZrTEA36ZgT+rKb8u0+5CcKbbt9pXaWOcqwnHko7R/FjUxD2o sTvoBVqG9RX6BEZWKGAWTOZbcj4wAIGap+1jbpE57Hh0kDrAcOU9e7N2K25Zzb1BhTzl 1uKdUg/gEnEQi4U+jW80PRWqADMzTMuEKr5UW+2TGwV4e9+MkTNl2OL67Vg4nl3ZFUsg 2Sd1siF4bEfmdubtk1X/nTjy1waVusT0ZiCYAlIO5FoWgxHsDQT5Kv1bjMf8qguhNP+M LKqg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=KEt5bCt4+kvFUYWh9A52JkpIaQ1BI8sVOrn4yplbLyM=; b=f51ZBPf8KK2mgKzsKYtBocMuObdUZxs9Z7pBRvnR6s5aoJCwLAGj0JW+mEcKTQ5+BG In+IMJlUOSzmrfH3OrbMFbyp0Za0QlVTDxwON70gCYZyYd77A84O2zd77qA9l9KdiXRF f7ofEN0+MrTUDdOPfSuY/AeC+ee5GcTinoNFPODH2Duv/51nGyU+ASaxA6jlHv0WaN04 +QQqxMwn4E5YqeD8b3VySbZ+VwQtGnaol7o7+QLB7y866lMUBh1GnZQk7+gUQ9LL/JVZ 4NAuLAo7vDC7sYC774t5ugv8jh7tVt6TqWk+UjH3W7WqDMAv0yUxcZ72fCpWdH+Gx4ae Np6A== X-Gm-Message-State: AO0yUKWCTRaFUNr1mFtadP/yatiyXhDy113QT4CusHOEcM1jLDo8rc0Z 7SQlU7XUUUKxlPlAcGO3JbA4AtK5KGE= X-Google-Smtp-Source: AK7set8JvvOZVCury8NiYN/8xMN1ULGqE+PDwtLM2YqAzOR5I/rZLaI9VbcT3yi+nn6d0ZL+jVlYXA== X-Received: by 2002:a05:6a00:1993:b0:592:5d3e:63d5 with SMTP id d19-20020a056a00199300b005925d3e63d5mr4218952pfl.5.1675271260849; Wed, 01 Feb 2023 09:07:40 -0800 (PST) Received: from ?IPV6:2601:681:8600:13d0::f0a? ([2601:681:8600:13d0::f0a]) by smtp.gmail.com with ESMTPSA id q6-20020aa79826000000b00592543d7363sm11221600pfl.1.2023.02.01.09.07.39 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 01 Feb 2023 09:07:40 -0800 (PST) Message-ID: Date: Wed, 1 Feb 2023 10:07:39 -0700 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.6.0 Subject: Re: [PATCH 2/2] riscv: vectorised mem* and str* functions Content-Language: en-US To: Florian Weimer , Jeff Law via Libc-alpha Cc: Sergei Lewis References: <20230201095232.15942-1-slewis@rivosinc.com> <20230201095232.15942-2-slewis@rivosinc.com> <972db14d-390f-f79a-bc56-41afce041257@gmail.com> <877cx1wd5c.fsf@oldenburg.str.redhat.com> From: Jeff Law In-Reply-To: <877cx1wd5c.fsf@oldenburg.str.redhat.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-2.4 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,NICE_REPLY_A,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 2/1/23 09:42, Florian Weimer wrote: > * Jeff Law via Libc-alpha: > >> On 2/1/23 02:52, Sergei Lewis wrote: >>> Initial implementations of memchr, memcmp, memcpy, memmove, memset, strchr, >>> strcmp, strcpy, strlen, strncmp, strncpy, strnlen, strrchr, strspn >>> targeting the riscv "V" extension, version 1.0 >>> The vectorised implementations assume VLENB of at least 128 and at >>> least 32 >>> registers (as mandated by the "V" extension spec). They also assume that >>> VLENB is a power of two which is no larger than the page size, and (as >>> vectorised code in glibc for other platforms does) that it is safe to read >>> past null terminators / buffer ends provided one does not cross a page >>> boundary. >>> Signed-off-by: Sergei Lewis >>> --- >>> sysdeps/riscv/rv64/rvv/Implies | 2 + >>> sysdeps/riscv/rv64/rvv/memchr.S | 127 +++++++++++++++++++ >>> sysdeps/riscv/rv64/rvv/memcmp.S | 93 ++++++++++++++ >>> sysdeps/riscv/rv64/rvv/memcpy.S | 154 +++++++++++++++++++++++ >>> sysdeps/riscv/rv64/rvv/memmove.c | 22 ++++ >>> sysdeps/riscv/rv64/rvv/memset.S | 89 ++++++++++++++ >>> sysdeps/riscv/rv64/rvv/strchr.S | 92 ++++++++++++++ >>> sysdeps/riscv/rv64/rvv/strchrnul.c | 22 ++++ >>> sysdeps/riscv/rv64/rvv/strcmp.S | 108 +++++++++++++++++ >>> sysdeps/riscv/rv64/rvv/strcpy.S | 72 +++++++++++ >>> sysdeps/riscv/rv64/rvv/strcspn.c | 22 ++++ >>> sysdeps/riscv/rv64/rvv/strlen.S | 67 ++++++++++ >>> sysdeps/riscv/rv64/rvv/strncmp.S | 104 ++++++++++++++++ >>> sysdeps/riscv/rv64/rvv/strncpy.S | 96 +++++++++++++++ >>> sysdeps/riscv/rv64/rvv/strnlen.S | 81 +++++++++++++ >>> sysdeps/riscv/rv64/rvv/strrchr.S | 88 ++++++++++++++ >>> sysdeps/riscv/rv64/rvv/strspn.S | 189 +++++++++++++++++++++++++++++ >> Does this need to be revamped given the recent push to do more with >> generic code and target specific hooks for mem* and str*? >> >> Shouldn't the implementations be in a multiarch directory? I would >> fully expect we're going to need both a vector and scalar >> implementation selected by an ifunc. > > I think most RISC-V GCC compilers won't have enabled IFUNC support? > Looking at gcc/config.gcc in GCC 12, I see this: > > *-*-linux* | *-*-gnu*) > case ${target} in > aarch64*-* | arm*-* | i[34567]86-* | powerpc*-* | s390*-* | sparc*-* | x86_64-* | loongarch*-*) > default_gnu_indirect_function=yes > ;; > esac > > But maybe that's not the right place to look at? Clearly something we need to fix. I'd hesitate to turn on the gcc bits without having the kernel/user interface settled. There was a proposal that added a syscall to get the processor capabilities -- I'd asked the authors to reach out to you and Carlos on whether or not that was acceptable for glibc. I'm not sure if that happened or not. > > We have an assembler hack to be able to still build IFUNC resolvers > written in C, but I don't know if this works on RISC-V. It probably doesn't yet. > > Ideally the GCC defaults would change, too, and well before IFUNCs are > in common use. They're not common, but I suspect that'll change in the next ~6 months. Jeff