From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by sourceware.org (Postfix) with ESMTP id 4D63A3858D20 for ; Thu, 28 Sep 2023 13:39:03 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 4D63A3858D20 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=arm.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=arm.com Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 4593E1FB; Thu, 28 Sep 2023 06:39:41 -0700 (PDT) Received: from localhost (e121540-lin.manchester.arm.com [10.32.110.72]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id ABAAA3F5A1; Thu, 28 Sep 2023 06:39:01 -0700 (PDT) From: Richard Sandiford To: HAO CHEN GUI Mail-Followup-To: HAO CHEN GUI ,"Kewen.Lin" , Segher Boessenkool , David , Peter Bergner , gcc-patches , Jeff Law , Jakub Jelinek , Richard Biener , richard.sandiford@arm.com Cc: "Kewen.Lin" , Segher Boessenkool , David , Peter Bergner , gcc-patches , Jeff Law , Jakub Jelinek , Richard Biener Subject: Re: [PATCH, rs6000] Enable vector compare for 16-byte memory equality compare [PR111449] References: Date: Thu, 28 Sep 2023 14:39:00 +0100 In-Reply-To: (HAO CHEN GUI's message of "Thu, 28 Sep 2023 16:10:14 +0800") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-18.5 required=5.0 tests=BAYES_00,KAM_DMARC_NONE,KAM_DMARC_STATUS,KAM_LAZY_DOMAIN_SECURITY,KAM_SHORT,SPF_HELO_NONE,SPF_NONE,TXREP autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: HAO CHEN GUI writes: > Kewen and Richard, > Thanks for your comments. Please let me clarify it. > > =E5=9C=A8 2023/9/27 19:10, Richard Sandiford =E5=86=99=E9=81=93: >> Yeah, I agree there doesn't seem to be a good reason to exclude vectors. >> Sorry to dive straight into details, but maybe we should have something >> called bitwise_mode_for_size that tries to use integer modes where possi= ble, >> but falls back to vector modes otherwise. That mode could then be used >> for copying, storing, bitwise ops, and equality comparisons (if there >> is appropriate optabs support). > > The vector mode is not supported for compare_by_pieces and move_by_piec= es. > But it is supported for set_by_pieces and clear_by_pieces. The help funct= ion > widest_fixed_size_mode_for_size returns vector mode when qi_vector is set= to > true. > > static fixed_size_mode > widest_fixed_size_mode_for_size (unsigned int size, bool qi_vector) Ah, had forgotten about that function. > > I tried to enable qi_vector for compare_by_pieces. It can pick up a vector > mode (eg. V16QImode) and works on some cases. But it fails on a constant > string case. > > int compare (const char* s1) > { > return __builtin_memcmp_eq (s1, "__GCC_HAVE_DWARF2_CFI_ASM", 16); > } > > As the second op is a constant string, it calls builtin_memcpy_read_str to > build the string. Unfortunately, the inner function doesn't support > vector mode. > > /* The by-pieces infrastructure does not try to pick a vector mode > for memcpy expansion. */ > return c_readstr (rep + offset, as_a (mode), > /*nul_terminated=3D*/false); > > Seems by-pieces infrastructure itself supports vector mode, but low level > functions do not. That looks easily solvable though. I've posted a potential fix as: https://gcc.gnu.org/pipermail/gcc-patches/2023-September/631595.html Is that the only blocker to doing this in generic code? Thanks, Richard > > I think there are two ways enable vector mode for compare_by_pieces. > One is to modify the by-pieces infrastructure . Another is to enable it > by cmpmem expand. The expand is target specific and be flexible. > > What's your opinion? > > Thanks > Gui Haochen