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 CFCDB3857001 for ; Wed, 27 Jul 2022 12:47:12 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org CFCDB3857001 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 102CAD6E; Wed, 27 Jul 2022 05:47:13 -0700 (PDT) Received: from localhost (e121540-lin.manchester.arm.com [10.32.98.37]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 92C233F73B; Wed, 27 Jul 2022 05:47:10 -0700 (PDT) From: Richard Sandiford To: Richard Biener Mail-Followup-To: Richard Biener , zhongjuzhe , gcc-patches@gcc.gnu.org, richard.earnshaw@arm.com, jakub@redhat.com, kenner@nyu.edu, jlaw@tachyum.com, gnu@the-meissners.org, jason@redhat.com, davem@redhat.com, joseph@codesourcery.com, bernds_cb1@t-online.de, ian@airs.com, wilson@tuliptree.org, richard.sandiford@arm.com Cc: zhongjuzhe , gcc-patches@gcc.gnu.org, richard.earnshaw@arm.com, jakub@redhat.com, kenner@nyu.edu, jlaw@tachyum.com, gnu@the-meissners.org, jason@redhat.com, davem@redhat.com, joseph@codesourcery.com, bernds_cb1@t-online.de, ian@airs.com, wilson@tuliptree.org Subject: Re: [PATCH 1/1] Fix bit-position comparison References: <20220727034437.154625-1-juzhe.zhong@rivai.ai> <20220727034437.154625-2-juzhe.zhong@rivai.ai> Date: Wed, 27 Jul 2022 13:47:09 +0100 In-Reply-To: (Richard Biener's message of "Wed, 27 Jul 2022 06:46:53 +0000 (UTC)") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Status: No, score=-53.6 required=5.0 tests=BAYES_00, GIT_PATCH_0, KAM_DMARC_NONE, KAM_DMARC_STATUS, KAM_LAZY_DOMAIN_SECURITY, SPF_HELO_NONE, SPF_NONE, 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 X-BeenThere: gcc-patches@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jul 2022 12:47:14 -0000 Richard Biener writes: > On Wed, 27 Jul 2022, juzhe.zhong@rivai.ai wrote: > >> From: zhongjuzhe >> >> gcc/ChangeLog: >> >> * expr.cc (expand_assignment): Change GET_MODE_PRECISION to GET_MODE_BITSIZE >> >> --- >> gcc/expr.cc | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/gcc/expr.cc b/gcc/expr.cc >> index 80bb1b8a4c5..ac2b3c07df6 100644 >> --- a/gcc/expr.cc >> +++ b/gcc/expr.cc >> @@ -5574,7 +5574,7 @@ expand_assignment (tree to, tree from, bool nontemporal) >> code contains an out-of-bounds access to a small array. */ >> if (!MEM_P (to_rtx) >> && GET_MODE (to_rtx) != BLKmode >> - && known_ge (bitpos, GET_MODE_PRECISION (GET_MODE (to_rtx)))) >> + && known_ge (bitpos, GET_MODE_BITSIZE (GET_MODE (to_rtx)))) > > I think this has the chance to go wrong with regard to endianess. > Consider to_rtx with 32bit mode size but 12bit mode precision. bitpos > is relative to the start of to_rtx as if it were in memory and bitsize > determines the contiguous region affected. But since we are actually > storing into a non-memory endianess comes into play. Not sure I follow the code well enough to comment, but: this condition is saying when we can drop the assignment on the floor and just expand the rhs (for side effects). From that point of view, using bitsize should be more conservative than using precision, since bitsize is always >= precision. Thanks, Richard > > So no, I don't think the patch is correct, it would be way more > complicated to get the desired improvement. > > Richard. > >> { >> expand_normal (from); >> result = NULL; >>