From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pg1-x534.google.com (mail-pg1-x534.google.com [IPv6:2607:f8b0:4864:20::534]) by sourceware.org (Postfix) with ESMTPS id 4A8343857BB2 for ; Tue, 15 Nov 2022 00:22:51 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 4A8343857BB2 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-pg1-x534.google.com with SMTP id q71so11740028pgq.8 for ; Mon, 14 Nov 2022 16:22:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=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=UQRwgPDlrf6UftLYmKiDJwRRORw9OkILmb38KRyMek4=; b=G21eBsBiDy53UjW2y1hkMOUxyjE9jw0UdzzH3Ig6Qx+UmG2Q0oa7JDtmiB7qLyKvdS TWIzLnlAWh6FiMwnsoD5QJvIA0YrgqKloLMx/UXcXopdyGgbdGD3YbHdU8Vnha8mmArl RY56xs4d0BTkbajH4mR25QrEoHsDDULoREotX7TDDeyR5PRXXHLnP0ARF4MeAZFWg2U1 XMNpmC1D6xJc67KxKYXohpfLL62FPTdJAq1UzqskivKx6oy9pDeMV++a+rjNbHwxLhsi IgVd/ZjOuRfPSr2j3eiNyIMJYT+WlDvpiwBsRFbigsp8KiMtOcInj/5VP41bTVNuOyuj PWsg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=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=UQRwgPDlrf6UftLYmKiDJwRRORw9OkILmb38KRyMek4=; b=EynD0zjs0gBNzWJUD4PNlL4wcTwaqfTSSvdOTPw7LVf9vzcxAYnFZ6hHJLO4CYFJmU FP/Ex0L+baYAE7mMJT8KgnNhVuSiFTPGb4S1gZplBnrPOjkaa9p2dXyf0mQq+azGsR2B oAHI2hvWaZruFlM6HfQlzLg4VjvcT0eccMBxlfE37vVVhzraEXua+h+0n1vWzhC/5sC9 nKfxaHmSw1IAF8BY5eDYWwPZjjMRX8sB8zmHJ8XIlPCvFmjJpayXbumQ1SJhK0EvW2ar 6xe/yjqC4oSSf4WRkIgluq9sfHxSlcn8mbiUIMWb4Tjon5v7Ey1wzInb4hv4gvSNLdwL tzUw== X-Gm-Message-State: ANoB5pl57Vdn5gqoD04V7iD3G/F108+49gAhrPFI0Swb4JBI15K9+FZP y0EJsOdZ8KIK+4TZv+RisZU= X-Google-Smtp-Source: AA0mqf7QCAoh9QUzW+mgtqYh/56X/8eatxZMpMQGS758QcdLWq77yj1YBPZ97n3bbxVgG437wLaAeA== X-Received: by 2002:a63:1666:0:b0:46f:9763:a37b with SMTP id 38-20020a631666000000b0046f9763a37bmr13783422pgw.177.1668471770255; Mon, 14 Nov 2022 16:22:50 -0800 (PST) Received: from ?IPV6:2601:681:8600:13d0::f0a? ([2601:681:8600:13d0::f0a]) by smtp.gmail.com with ESMTPSA id x12-20020a170902ec8c00b0017f6c9622b9sm8220822plg.183.2022.11.14.16.22.48 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 14 Nov 2022 16:22:49 -0800 (PST) Content-Type: multipart/alternative; boundary="------------eKL9cJeCfP6jDKAO0YoR7KyB" Message-ID: <6395fbc9-6874-55f9-9ea0-5d4f87b1b83e@gmail.com> Date: Mon, 14 Nov 2022 17:22:47 -0700 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.3.1 Subject: Re: [PATCH 7/7] riscv: Add support for str(n)cmp inline expansion Content-Language: en-US To: =?UTF-8?Q?Christoph_M=c3=bcllner?= Cc: gcc-patches@gcc.gnu.org, Kito Cheng , Jim Wilson , Palmer Dabbelt , Andrew Waterman , Philipp Tomsich , Vineet Gupta References: <20221113230521.712693-1-christoph.muellner@vrull.eu> <20221113230521.712693-8-christoph.muellner@vrull.eu> <7b26ef79-50c7-b4df-f0a7-e2fd40767d8d@gmail.com> From: Jeff Law In-Reply-To: X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,HTML_MESSAGE,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: This is a multi-part message in MIME format. --------------eKL9cJeCfP6jDKAO0YoR7KyB Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 11/14/22 14:49, Christoph Müllner wrote: > > > We can take this further, but then the following questions pop up: > * how much data processing per loop iteration? I have no idea because I don't have any real data.  Last time I gathered any data on this issue was circa 1988 :-) > * what about unaligned strings? I'd punt.  I don't think we can depend on having a high performance unaligned access.  You could do a dynamic check of alignment, but you'd really need to know that they're aligned often enough that the dynamic check can often be recovered. > > Happy to get suggestions/opinions for improvement. I think this is pretty good without additional data that would indicate that handling unaligned cases or a different number of loop peels would be a notable improvement. Jeff --------------eKL9cJeCfP6jDKAO0YoR7KyB--