From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-il1-x12b.google.com (mail-il1-x12b.google.com [IPv6:2607:f8b0:4864:20::12b]) by sourceware.org (Postfix) with ESMTPS id B586C3858D28 for ; Fri, 31 Mar 2023 22:10:27 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org B586C3858D28 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-il1-x12b.google.com with SMTP id h11so12238156ild.11 for ; Fri, 31 Mar 2023 15:10:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; t=1680300626; x=1682892626; 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=/G32Kugkac/LToR+G/N0bIF1DoYPKOiHT++BMTbUmZ0=; b=VHgZo2Blyx9Iwp9Xa1Oq53dXcDuD87nEnNBFn2xL6Xb1PZfbmbjU8s78EKOy5agQ/S m4PkmpWUMLhMJRlWn4cbcAaHgAGkLXuytZJvn9btpu6oB9uQLaq3B+3JPZMgVK0/mbY0 urPz8muWBoJs+nlyH0qq2Dm0PAvNLzPZPDCYVHoSbO5PQJweZ603rOf1lW6J1KG0JQwo kn2snINkI3E8/ozR3rteYJrJfDT6eGHBNBOCMe2b8cQiU6drVbOBiwwIKWIF2+yV10hz 4UCOgJY8cdQMvKRSB8BahfTB/XMJ3lKpTN2d3fufQPJA/oXZIpIHNWxlU71mVBj+f0cE XIUw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1680300626; x=1682892626; 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=/G32Kugkac/LToR+G/N0bIF1DoYPKOiHT++BMTbUmZ0=; b=jPSwnbLe/blsCBCSQ3RO5YsJCYwKRCykMSU2+Oz+dktNzjCCAdXWaAVbgKhCiMIPNZ wIcOCbhojSJQZGB/PW4TDTfWHDcH6njjyD/qTWJGuMPDRbctL1NamuBDUEx7hlA0EXd3 5zPoNy+iUD8SZxl16m5DxQt2OTDZ5KBxvdaqcLnHLyvdxXcljqDWSbV714/J1p3966Un nUQCqqFfN0sAY2qxzMyKFWAwdA9l5uaaccEr4ThZQ4Pvwa6zNT6yCXF8Hh53tZi2WxqO e77YIERoLzSUPSuvrkV4cNa2ybcY3CURkruupvaZijNtIPh1bbAw6wOKQbPaQZOdndlq ztFQ== X-Gm-Message-State: AAQBX9do/qvtd+1vZd3xyp5SRgDef3tJckF6DRC7MJSxXvfxh7g8+Kcm +8UPzqkkrpw8T5Mg774fh0M= X-Google-Smtp-Source: AKy350ZUThofDOFLXDw4SkYn5YNeXuReqaZrPkiTO/iK9Juk8rdFgipIEb9w8PgdvZ39K89UqEsEbA== X-Received: by 2002:a92:d8d1:0:b0:315:6fc5:ea46 with SMTP id l17-20020a92d8d1000000b003156fc5ea46mr19852650ilo.2.1680300626286; Fri, 31 Mar 2023 15:10:26 -0700 (PDT) Received: from ?IPV6:2601:681:8600:13d0::f0a? ([2601:681:8600:13d0::f0a]) by smtp.gmail.com with ESMTPSA id w17-20020a056638379100b004063fa63e31sm909663jal.118.2023.03.31.15.10.25 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 31 Mar 2023 15:10:25 -0700 (PDT) Message-ID: <61b659b7-7c08-028a-1e7a-2e1b19df080a@gmail.com> Date: Fri, 31 Mar 2023 16:10:24 -0600 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.9.0 Subject: Re: [PATCH v2 0/3] RISC-V: ifunced memcpy using new kernel hwprobe interface Content-Language: en-US To: Palmer Dabbelt Cc: adhemerval.zanella@linaro.org, Evan Green , libc-alpha@sourceware.org, slewis@rivosinc.com, Vineet Gupta References: From: Jeff Law In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-2.3 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 3/31/23 15:38, Palmer Dabbelt wrote: > On Fri, 31 Mar 2023 14:35:36 PDT (-0700), jeffreyalaw@gmail.com wrote: >> >> >> On 3/31/23 15:03, Palmer Dabbelt wrote: >>> On Fri, 31 Mar 2023 13:19:19 PDT (-0700), jeffreyalaw@gmail.com wrote: >>> >>> [just snipping the rest so we can focus on Jeff's ask, the other stuff >>> is interesting but a longer reply and we'd probably want to fork the >>> thread anyway...] >>> >>>> So perhaps we can narrow down the scope right now even further.  Can we >>>> agree to try and settle on a base implementation with no ISA extensions >>>> and no uarch variants?  ISTM if we can settle on those implementations >>>> that it should be usable immediately by the RV community at large and >>>> doesn't depend on the kernel->glibc interface work. >>> >>> That base includes V and ZBB?  In that case we'd be dropping support for >>> all existing hardware, which I would be very much against. >> No, it would not include V or ZBB.  It would be something that could >> work on any risc-v hardware.  Sorry if I wasn't clear about that. > > I'm still kind of confused then, maybe it's just too abstract?  Is there > something you could propose as being the base? So right now we use the generic (architecture independent) routines for str* and mem*. If we look at (for example) strcmp there's hand written variants out there are are purported to have better performance than the generic code in glibc. Note that any such performance claims likely predate the work from Adhemerval and others earlier this year to reduce the reliance on hand-coded assembly. So the first step is to answer the question, for any str* or mem* where we've received a patch submission of a hand coded assembly variant (which isn't using ZBB or V), does that hand coded assembly variant significantly out perform the generic code currently in glibc. If yes and the generic code can't be significantly improved, then we should declare that hand written variant as the standard baseline for risc-v in glibc. Review, adjust, commit and move on. My hope would be that many (most, all?) of the base architecture hand coded assembly variants no longer provide any significant benefit over the current generic versions. That's my minimal proposal for now. It's not meant to solve everything in this space, but at least carve out a chunk of the work and get it resolved one way or the other. Does that help clarify what I'm suggesting? Jeff