From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from gate.crashing.org (gate.crashing.org [63.228.1.57]) by sourceware.org (Postfix) with ESMTP id C79093858D28 for ; Wed, 12 Apr 2023 15:26:28 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org C79093858D28 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=kernel.crashing.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=kernel.crashing.org Received: from gate.crashing.org (localhost.localdomain [127.0.0.1]) by gate.crashing.org (8.14.1/8.14.1) with ESMTP id 33CFONWV007851; Wed, 12 Apr 2023 10:24:23 -0500 Received: (from segher@localhost) by gate.crashing.org (8.14.1/8.14.1/Submit) id 33CFOMV1007850; Wed, 12 Apr 2023 10:24:22 -0500 X-Authentication-Warning: gate.crashing.org: segher set sender to segher@kernel.crashing.org using -f Date: Wed, 12 Apr 2023 10:24:22 -0500 From: Segher Boessenkool To: Jakub Jelinek Cc: Jeff Law , Eric Botcazou , gcc-patches@gcc.gnu.org, Richard Biener , Richard Sandiford Subject: Re: [PATCH] combine, v3: Fix AND handling for WORD_REGISTER_OPERATIONS targets [PR109040] Message-ID: <20230412152422.GC19790@gate.crashing.org> References: <2220543.iZASKD2KPV@fomalhaut> <3412470.QJadu78ljV@fomalhaut> <8d3c3861-c291-e762-a2a8-0b520f39a7e3@gmail.com> <965831db-ac9e-cc5e-3459-08b6b70fd577@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-Spam-Status: No, score=-2.8 required=5.0 tests=BAYES_00,JMQ_SPF_NEUTRAL,KAM_DMARC_STATUS,SPF_HELO_PASS,SPF_PASS,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: On Wed, Apr 12, 2023 at 12:02:12PM +0200, Jakub Jelinek wrote: > On Wed, Apr 12, 2023 at 08:21:26AM +0200, Jakub Jelinek via Gcc-patches wrote: > > I would have expected something like > > WORD_REGISTER_OPERATIONS && known_le (GET_MODE_PRECISION (mode), BITS_PER_WORD) > > as the condition to use word_mode, rather than just > > WORD_REGISTER_OPERATIONS. In both spots. Because larger modes should be > > used as is, not a narrower word_mode instead of them. > > In patch form that would be following (given that the combine.cc change > had scalar_int_mode mode we can as well just use normal comparison, and > simplify-rtx.cc has it guarded on HWI_COMPUTABLE_MODE_P, which is also only > true for scalar int modes). > > I've tried the pr108947.c testcase, but I see no differences in the assembly > before/after the patch (but dunno if I'm using the right options). > The pr109040.c testcase from the patch I don't see the expected zero > extension without the patch and do see it with it. > > As before, I can only test this easily on non-WORD_REGISTER_OPERATIONS > targets. There are no doubt tens more similar WORD_REGISTER_OPERATIONS problems lurking. We would be much better off if this wart was removed and we handled such things properly. That said: > PR target/109040 > * combine.cc (simplify_and_const_int_1): Compute nonzero_bits in > word_mode rather than mode if WORD_REGISTER_OPERATIONS and mode is > smaller than word_mode. > * simplify-rtx.cc (simplify_context::simplify_binary_operation_1) > : Likewise. > > * gcc.c-torture/execute/pr109040.c: New test. Okay for trunk. Thanks! Segher