From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ot1-x333.google.com (mail-ot1-x333.google.com [IPv6:2607:f8b0:4864:20::333]) by sourceware.org (Postfix) with ESMTPS id 503B638582AC for ; Mon, 14 Nov 2022 19:28:31 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 503B638582AC 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-ot1-x333.google.com with SMTP id a7-20020a056830008700b0066c82848060so7255057oto.4 for ; Mon, 14 Nov 2022 11:28:31 -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:to :content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=XdS9BJ2A1H/KRw86wslc7eJQIhl6KBBQtrOK6xzUsKw=; b=o2pxBq9S8ITvLbkIAXJb23rxs8vfkXiEQ1up12vV8r3UqK1l60pXDAqiEtvQJfQrBR r0LmJgwtfr5RSmuH6dS0bswMiiLGkybCSAHq7RM+BVuuOk8iEpOMmNWesoXSaN9WDC4y csMI0jlBg9dvZyOW5g8vpCypm+lfC7BYN0KATkOjWum5PXbyPfpchs/KY3h1164UmcNe DAm8qRXNO6SiK2rRuxB8V2+tFxUr76KqoNQDVQclXEfa6YVw+NiP6FGJHbpWXU6xVB9P N8vbyJ0i8AUlMxOjtgUU2QzjnPtgWEH+xWIjXQ2vMuNXqCc1qURfhNBu4wF/nVqLMQSW Gugw== 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: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=XdS9BJ2A1H/KRw86wslc7eJQIhl6KBBQtrOK6xzUsKw=; b=wm94vXRttd4shDeR9Q8soFV6xCmLT/jM4fmHyql2mafFSj1aPYdxxbsJXGA+V08S9O 5vwfYkNirlBxT0SZXgS6QJMmA0hphJrUBUsIezs5ZFRYTQuf9r1xVh1QctMpzwuMrQLU rvv1afbUO/XRmrwp4Mwww84gzg8ErKRbz8/5QqgiVtHpSaoiovacxJNvVeXj+8TBRNWI VCr2+z/P2gwby1ExS6C3RaqjJ+nKv9U6l9sHm7QImqdZ4mIqUxzT19tUsYKGnjz1JXUj J6G74Xx2Qi8CJQmx5ZIFPbr5nEgmam6yM/2mjseVBZo/MIMeN+zO9OW5g44s/+jmfzGC yp9w== X-Gm-Message-State: ANoB5pl7qYUEo0MgnMzSYNTxa2waaRkzy1Jc2xlauFan3mZNQgpsIDbJ Locn3OqoOdtRNFWXFIvifAY= X-Google-Smtp-Source: AA0mqf50x+r5bwb9XEAXGxEiv2fmPUesY9Im5Vb6kv3v7ExfMGBY87NSizTNekUN4D/pWwt0EqatnA== X-Received: by 2002:a05:6830:698b:b0:66b:3596:953e with SMTP id cy11-20020a056830698b00b0066b3596953emr7238190otb.158.1668454110481; Mon, 14 Nov 2022 11:28:30 -0800 (PST) Received: from ?IPV6:2601:681:8600:13d0::f0a? ([2601:681:8600:13d0::f0a]) by smtp.gmail.com with ESMTPSA id s1-20020a4aad41000000b004968311a31asm3924910oon.39.2022.11.14.11.28.28 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 14 Nov 2022 11:28:29 -0800 (PST) Message-ID: <7b26ef79-50c7-b4df-f0a7-e2fd40767d8d@gmail.com> Date: Mon, 14 Nov 2022 12:28:28 -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: Christoph Muellner , 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> From: Jeff Law In-Reply-To: <20221113230521.712693-8-christoph.muellner@vrull.eu> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit 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,KAM_MANYTO,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 11/13/22 16:05, Christoph Muellner wrote: > From: Christoph Müllner > > This patch implements expansions for the cmpstrsi and the cmpstrnsi > builtins using Zbb instructions (if available). > This allows to inline calls to strcmp() and strncmp(). > > The expansion basically emits a peeled comparison sequence (i.e. a peeled > comparison loop) which compares XLEN bits per step if possible. > > The emitted sequence can be controlled, by setting the maximum number > of compared bytes (-mstring-compare-inline-limit). > > gcc/ChangeLog: > > * config/riscv/riscv-protos.h (riscv_expand_strn_compare): New > prototype. > * config/riscv/riscv-string.cc (GEN_EMIT_HELPER3): New helper > macros. > (GEN_EMIT_HELPER2): New helper macros. > (expand_strncmp_zbb_sequence): New function. > (riscv_emit_str_compare_zbb): New function. > (riscv_expand_strn_compare): New function. > * config/riscv/riscv.md (cmpstrnsi): Invoke expansion functions > for strn_compare. > (cmpstrsi): Invoke expansion functions for strn_compare. > * config/riscv/riscv.opt: Add new parameter > '-mstring-compare-inline-limit'. Presumably the hybrid inline + out of line approach is to capture the fact that most strings compare unequal early, then punt out to the library if they don't follow that model?  It looks like we're structured for that case by peeling iterations rather than having a fully inlined approach.  Just want to confirm... I was a bit worried about the "readahead" problem that arises when reading more than a byte and a NUL is found in the first string.  If you're not careful, the readahead of the second string could fault.  But it looks like we avoid that by requiring word alignment on both strings. > + > +/* Emit a string comparison sequence using Zbb instruction. > + > + OPERANDS[0] is the target (result). > + OPERANDS[1] is the first source. > + OPERANDS[2] is the second source. > + If NO_LENGTH is zero, then: > + OPERANDS[3] is the length. > + OPERANDS[4] is the alignment in bytes. > + If NO_LENGTH is nonzero, then: > + OPERANDS[3] is the alignment in bytes. Ugh.  I guess it's inevitable unless we want to drop the array and pass each element individually (in which case we'd pass a NULL_RTX in the case we don't have a length argument). I'd like to give others a chance to chime in here.  Everything looks sensible here, but I may have missed something.  So give the other maintainers a couple days to chime in before committing. Jeff