From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pl1-x635.google.com (mail-pl1-x635.google.com [IPv6:2607:f8b0:4864:20::635]) by sourceware.org (Postfix) with ESMTPS id 605593857C43 for ; Tue, 15 Nov 2022 03:41:36 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 605593857C43 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-pl1-x635.google.com with SMTP id k7so11986412pll.6 for ; Mon, 14 Nov 2022 19:41:36 -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=W4lfEvXldxJKZ9NrP3DYhTVy2mXBmiDLtCNgu/c7NJQ=; b=iilTxnwCrZbzDgBnXJ7zPQUg+1nH7eVruPLc9gLbyjvTCk/rkAVjLdkFc/XVz80qA6 Bt/tNzlce4GyLbTbn+PoE0hsz3N2kMLPan6lzluuFaEZthXbrpJZxJl+E7mV7RBWJnA6 e5Y5Pj38I7kVF8KUBXwNP1ARYlUp4q9mGa91Yt3VZdwIkP1UeZZBKSp1zCuxSgnDdxGi QpVey+4XVz6TdDzZhYpCp1fSnkl9tBhFv2Z2gcvuIFdcc+EwQvTJLTg5zqfabxfPee0F GkSoAftnrQ8aYt6unJBd/sj6Hnj68CEV/wZUBOrsnvwE+0Cctt2e1g5Uk2WINrMlcAjd Fivg== 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=W4lfEvXldxJKZ9NrP3DYhTVy2mXBmiDLtCNgu/c7NJQ=; b=IAPfl/TDg3lLkWuBgMZnhmuiVVmFS5T8rYL51wR+/q/2BlZBQgjtRhrI0ihLCzgZh5 wZMJ0pVB9uSk5qLat9l3UPHB/v+jnRE+qYwK8sQEY2DJ8Xxsx+JC/IBlWVe+HiFZyA7F 0qj2CR9i7mMCTgfk7DHnze9oHCuGkjn7kYxlodobetFK9r6533xRAsq31d84mvpbwmY2 sXpm6INovaMlEx1DWxyzyHuNPOqkz7GGZU225YdZ+SiPqddAUZeyEWfoctLvkwarEnOB 5IdigwodeUvDKJcdWnQflBusWh3M2NfdqZ/LB91P6MvPfJV2Tfoug9FwFlx4hjK2vzap FF8g== X-Gm-Message-State: ANoB5plPB1S+Rrr4g3jeFwaFuWXK5BidxNvAgV00ipq9woxEteDm4qIh noCgsp79DtLjQMPkhMWvX/g= X-Google-Smtp-Source: AA0mqf4MnTNIWRoKoaNERlnz2G19IW371hVqLJVxThD9RnAUelV2cFJvR0dKJrj4uFSw+5QvJRWfKg== X-Received: by 2002:a17:902:6b07:b0:186:880c:1680 with SMTP id o7-20020a1709026b0700b00186880c1680mr2138056plk.164.1668483695145; Mon, 14 Nov 2022 19:41:35 -0800 (PST) Received: from ?IPV6:2601:681:8600:13d0::f0a? ([2601:681:8600:13d0::f0a]) by smtp.gmail.com with ESMTPSA id 76-20020a62154f000000b0056c063dd4cfsm7545814pfv.66.2022.11.14.19.41.33 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 14 Nov 2022 19:41:34 -0800 (PST) Message-ID: <72b242a2-b111-d870-7f7d-f7e5f5801140@gmail.com> Date: Mon, 14 Nov 2022 20:41:32 -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: Palmer Dabbelt , Kito Cheng Cc: christoph.muellner@vrull.eu, gcc-patches@gcc.gnu.org, kito.cheng@sifive.com, Jim Wilson , Andrew Waterman , philipp.tomsich@vrull.eu, 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=-1.0 required=5.0 tests=BAYES_00,BODY_8BITS,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 11/14/22 17:53, Palmer Dabbelt wrote: > On Mon, 14 Nov 2022 16:46:37 PST (-0800), Kito Cheng wrote: >> Hi Christoph: >> >>> 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). >> >> I would like to have a unified option interface, >> maybe -m[no-]inline-str[n]cmp and -minline-str[n]cmp-limit. >> And add some option like this: >> -minline-str[n]cmp=[bitmanip|vector|auto] in future, >> since I assume we'll have different versions of those things. > > Can we just decide that from mtune?  We'll probably have > uarch-specific string functions at some point, might as well start > planning for it now. Sure, though the implementation isn't terribly tied to any uarch at the moment and I doubt uarch approaches would make significant impacts here -- we're peeling off some small number of iterations fairly generically.  The uarch specific stuff would be the code in glibc selected by an ifunc.  uarch variants for block copiers seem inevitable though :-) I don' t have strong opinions here, so if we want to key off mtune, sure.  If we want to have variants for scalar vs vector that's quite reasonable too.  Or if we want to go all the way to uarch specific implementations, I won't object. > th >>> 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'. >> >> We need to document this option. Yes, definitely needs documentation.  Thanks for catching that. jeff