From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from xry111.site (xry111.site [89.208.246.23]) by sourceware.org (Postfix) with ESMTPS id 37FEB38582AE for ; Mon, 18 Dec 2023 16:48:53 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 37FEB38582AE Authentication-Results: sourceware.org; dmarc=pass (p=reject dis=none) header.from=xry111.site Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=xry111.site ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 37FEB38582AE Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=89.208.246.23 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1702918134; cv=none; b=NbWJQp9Yqx9MoYEI2BUinyE9IoR+PC+jw1TIZj15wY2MVu5IpnUAjhylp+dWwo2BIWASIWYBBUpvpx1Csa665dlcG3V8NMzW/TpsicXl0LlQHePSknOqq8aIk1pxY6gEvSivmL0aks3E8JK496kW+c39DDLL1ii5lfCk1feM9Mg= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1702918134; c=relaxed/simple; bh=dSTgpHyQtmJbsAqlp3Dtqgl3lYy7iziHeqCQ40opyo8=; h=DKIM-Signature:Message-ID:Subject:From:To:Date:MIME-Version; b=uqR5ZcGlkKkTT0T9SHBN/qY/UvD4lDmhYrlJS+rU4SIxb0KzEKu3zA5K4UkV6mn/oCw3EbbMTenPct/1TgrAwS6becR0x3YG3cGCqWuv8fXSZbTVLerC/fV/r7QlemVuGAmXEUkvK7WRyPNy5148Nygw6HPhqal9EIYAMdtUAfA= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=xry111.site; s=default; t=1702918130; bh=dSTgpHyQtmJbsAqlp3Dtqgl3lYy7iziHeqCQ40opyo8=; h=Subject:From:To:Cc:Date:In-Reply-To:References:From; b=cWSrxWlrdcw/sWHGuW1WJvgJ9KQHU4QclILXLWn0l3j/ZXVf0c4g1LyqCEzGBTzFv 19qpI1vNLQvKYqTqrLN0qADhr7Pzv2SrUtHCtubKlxrWj4FwWjBCRl0JRZjr8v0TMx Osd2UhqHlhObbbvibUtC3L52NHS3CM6if4brLuX8= Received: from [127.0.0.1] (unknown [IPv6:2001:470:683e::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature ECDSA (P-384) server-digest SHA384) (Client did not present a certificate) (Authenticated sender: xry111@xry111.site) by xry111.site (Postfix) with ESMTPSA id 9464766F53; Mon, 18 Dec 2023 11:48:48 -0500 (EST) Message-ID: Subject: Re: [PATCH] middle-end: Call negate_rtx instead of simplify_gen_unary expanding rotate shift [PR113033] From: Xi Ruoyao To: Jeff Law , gcc-patches@gcc.gnu.org Cc: Jakub Jelinek , chenglulu , i@xen0n.name, xuchenghua@loongson.cn, c@jia.je Date: Tue, 19 Dec 2023 00:48:46 +0800 In-Reply-To: References: <20231218134251.1513432-1-xry111@xry111.site> Autocrypt: addr=xry111@xry111.site; prefer-encrypt=mutual; keydata=mDMEYnkdPhYJKwYBBAHaRw8BAQdAsY+HvJs3EVKpwIu2gN89cQT/pnrbQtlvd6Yfq7egugi0HlhpIFJ1b3lhbyA8eHJ5MTExQHhyeTExMS5zaXRlPoiTBBMWCgA7FiEEkdD1djAfkk197dzorKrSDhnnEOMFAmJ5HT4CGwMFCwkIBwICIgIGFQoJCAsCBBYCAwECHgcCF4AACgkQrKrSDhnnEOPHFgD8D9vUToTd1MF5bng9uPJq5y3DfpcxDp+LD3joA3U2TmwA/jZtN9xLH7CGDHeClKZK/ZYELotWfJsqRcthOIGjsdAPuDgEYnkdPhIKKwYBBAGXVQEFAQEHQG+HnNiPZseiBkzYBHwq/nN638o0NPwgYwH70wlKMZhRAwEIB4h4BBgWCgAgFiEEkdD1djAfkk197dzorKrSDhnnEOMFAmJ5HT4CGwwACgkQrKrSDhnnEOPjXgD/euD64cxwqDIqckUaisT3VCst11RcnO5iRHm6meNIwj0BALLmWplyi7beKrOlqKfuZtCLbiAPywGfCNg8LOTt4iMD Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.50.2 MIME-Version: 1.0 X-Spam-Status: No, score=-0.3 required=5.0 tests=BAYES_00,BODY_8BITS,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,LIKELY_SPAM_FROM,SPF_HELO_PASS,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE 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 Mon, 2023-12-18 at 08:39 -0700, Jeff Law wrote: >=20 >=20 > On 12/18/23 06:42, Xi Ruoyao wrote: > > With simplify_gen_unary we end up with a not fully expanded RTX like > >=20 > > =C2=A0=C2=A0=C2=A0=C2=A0 (set (reg:SI 90) (and:SI (neg:SI (reg:SI 80)) = (const_int 63))) > >=20 > > Then it will cause an ICE with unrecognizable insn. > >=20 > > gcc/ChangeLog: > >=20 > > PR middle-end/113033 > > * expmed.cc (expand_shift_1): When expanding rotate shift, call > > negate_rtx instead of simplify_gen_unary (NEG, ...). > The key difference being that using negate_rtx will go through the=20 > expander which knows how to synthesize negation whereas=20 > simplify_gen_unary will just generate a (neg ...) and assume it matches= =20 > something in the backend, right? For PR113033 the key difference (to me) is negate_rtx emits an insn to set a new pseudo reg to -x. So the result will be (set (reg:SI 81) (neg:SI (reg:SI 80))) then (and (reg:SI 81) (const_int 31)) instead of a consolidated (and:SI (neg:SI (reg:SI IN)) (const_int 63)) AFAIK no backends have an instruction doing "negate an operand then and bitwisely". To me, technically the following operation other_amount =3D simplify_gen_binary (AND, GET_MODE (op1), other_amount, gen_int_mode (mask, GET_MODE (op1))); should also be something negate_rtx too or we may still end up with an ICE with backends incapable to match (set (reg:SI XX) (and (reg:SI 81) (const_int 31))) But fortunately most backends has an immediate and operation so it's unlikely to blow up... > If so, this patch is fine for the trunk. --=20 Xi Ruoyao School of Aerospace Science and Technology, Xidian University