From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-io1-xd2e.google.com (mail-io1-xd2e.google.com [IPv6:2607:f8b0:4864:20::d2e]) by sourceware.org (Postfix) with ESMTPS id B47273858D28 for ; Fri, 31 Mar 2023 20:19:21 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org B47273858D28 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-io1-xd2e.google.com with SMTP id m22so10224970ioy.4 for ; Fri, 31 Mar 2023 13:19:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; t=1680293961; x=1682885961; 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=r/L/DhodU3QK8H04NExmFi/QAA61vQLzZMcoBWqLPSw=; b=psoqrVZ50Lq42680w6BB2oDyMz1DtLJC8oZ6gilKiYCTtSyb46Y+C2X7xaPkO9E9Ci QA49nW4+wqdDg4rCy+Je3yJK11C5lRTo5s8L8yPufJid3hY37DvDasLr/n68oaDSFZQ7 wh06me1uZliDgueQCEbGiZsNMVQMotZyurzg1DkTdIFGNCAR8GYsL7g1YARz+n3g0/35 i5JxuCA056ay7s4n5m/5XnEdGLLbSaVdzUUD+d3q7GlPfXqbZL5WKCwjIO4YSu6qykSW 6K9IrMbOmuiIqZv6A9b8fWfhQpJxICQPz8BFQQCBfWbsfca89WnYR9Pu6mgAFummmAKJ YjhQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1680293961; x=1682885961; 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=r/L/DhodU3QK8H04NExmFi/QAA61vQLzZMcoBWqLPSw=; b=nv+b2ik0spGhjcojL3cjnRsUPthhHtJKIsQops0+SExsoT5WI907h2yYg7PCv8gZMl B8h0hP6bOv1IsvUkBOxA3X7nLUS5rrWy6sFoBHndRRsULGgcZZXtxMj+KwVKxV1sJ2um xYpJ4uwsCsmcapxd+FqcHOXTeowsy/VcLZjlVI6cC8r9OvdZ/4xlwLtLRB6q+WhfYRgy qWpyrx5gDCFHkBMUckPMXZ+5+LO43ejvwmK52Qrz0ZzlhP92WRvuYhu7UZ8pmSb39zqd g8zt7ZJP3j/6U/ltz4K+t04F8Sj1/157dkQVJcgXrcaPN5iPm9SRpRFLUwwcZ22CDLe/ Mzrw== X-Gm-Message-State: AO0yUKWzxWhkbxonP6oEmuI6x0WWpOeAfP37jfKXripjy061x8Gk6ryQ 9dUlcGppz5g5rjpLHMyGBRs= X-Google-Smtp-Source: AK7set+cClDgpJxBJSkTKHlTV5lluWGuuFZuQU2cr537oyZGSP3df82MKogZadHW2kb1qKvlwki6WQ== X-Received: by 2002:a5d:984c:0:b0:755:ef36:b219 with SMTP id p12-20020a5d984c000000b00755ef36b219mr19348801ios.1.1680293960864; Fri, 31 Mar 2023 13:19:20 -0700 (PDT) Received: from ?IPV6:2601:681:8600:13d0::f0a? ([2601:681:8600:13d0::f0a]) by smtp.gmail.com with ESMTPSA id bm12-20020a05663842cc00b0040631e8bf89sm861199jab.38.2023.03.31.13.19.19 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 31 Mar 2023 13:19:20 -0700 (PDT) Message-ID: <44f66aa6-346f-99c7-0a9c-de9fa0bcd490@gmail.com> Date: Fri, 31 Mar 2023 14:19:19 -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: Adhemerval Zanella Netto , Palmer Dabbelt Cc: Evan Green , libc-alpha@sourceware.org, slewis@rivosinc.com, Vineet Gupta References: <71550310-e6ef-dfa1-db3b-dcd7407fd413@linaro.org> From: Jeff Law In-Reply-To: <71550310-e6ef-dfa1-db3b-dcd7407fd413@linaro.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit 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 13:32, Adhemerval Zanella Netto wrote: > > It is still not clear to me what RISCV, as ABI and not as an specific vendor, > wants to provide arch and vendor specific str* and mem* routines. Christophe > has hinted that the focus is not compile-only approach, so I take --with-cpu > support (similar to what some old ABI used to provide, like powerpc) is not > an option. However, this is not what the RVV proposal does [3], which is to > enable RVV iff you target glibc to rvv (so compile-only). I believe there is consensus on the desire to use dynamic dispatch via an ifunc resolver. > > And that's why I asked you guys to first define on how you want to approach > it. I think that's already done. I don't really see any confusion in this space. The patch from the sifive team has static dispatch, they made it clear they want dynamic dispatch though. Static dispatch is just a stopgap until the dynamic dispatch work is ready AFAICT. rivos had a dynamic dispatch mechanism based on riscv_hwprobe VRULL had a dynamic dispatch based on an environment variable. This was acknowledged to be a hack which would be dropped once the kernel->glibc interface bits were sorted out. Ventana doesn't have patches in this space, but had been using the VRULL bits. I don't really have a preference as far as implementations. I just want to define good ones that cover the most important cases, particularly with regard to ISA extensions, but I'm even willing to narrow the immediate focus down further (see below). > > So I take that RISCV want to follow what x86_64 and aarch64 do, which is > provide optimized routines for a minimum abi (say rv64gc), and then provide > runtime selection through ifunc for either ABI or vendor specific routines > (including variant like the unaligned optimization). Right. That's basically what I think we're trying to do. Find a suitable implementation we can agree upon for a given ISA architecture. The belief right now is that we need one for the baseline architecture, one for architectures implementing ZBB and another for architectures that implement RVV. ZBB and RVV are not uarch variants; they are standardized, but optional ISA features. I don't think anyone is (yet!) pushing for uarch variants. In fact, I would very much like to avoid that as much as I can. Palmer might see uarch variants are inevitable, I don't (and maybe I'm being naive). You can still follow > what x86_64 and s390 recently did, which is if you define a minimum ABI > version, you default the optimized version and either skip ifunc selection > or setup a more restrict set (so in future, you can have a rvv-only build > that does not need to provide old zbb or rv64gc support). I'm focused on defining a implementation for the baseline architecture as well as one for ZBB and RVV ISAs. > > Which then leads to how to actually test and provide such support. The > str* and mem* tests consult which ifunc variant are support > (ifunc-impl-list.c) on the underlying hardware; while the selector returns > the best option. Both rely on how to query the hardware at or least which > version are supported, so I think RISCV should first figure out this part > (unless you do want to follow the compile-only approach...) > > So it does not make sense to me to have ifunc variants not selected or > tested in repo, only to be enabled in a foreseen future. I think this is the core point we disagree on. I understand your position, respectfully disagree, but I'm willing to set it aside. 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. Jeff