From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 8E8B83858C50; Fri, 28 Apr 2023 20:26:18 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 8E8B83858C50 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1682713578; bh=96VicNGfRbktUzykRPhGFq2dYh3I+3jedBYsePJMM3M=; h=From:To:Subject:Date:In-Reply-To:References:From; b=ZPqOAUZ0lnN5W48F/hzpcZm3X9EQB8Wp4CBml90xRqbX3d6uEfF0VmjBW9is/W4xC i7xcujUb8gAohABKscKiGoI/B9CbXBIljjLR2kwBZ0mST16xsVwWNQ19kH8ZS7V8bz lej8H0IYIc4ZB1NMeYwiVGr8ZMgskbhvYtsC/Cd4= From: "law at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug rtl-optimization/109592] Failure to recognize shifts as sign/zero extension Date: Fri, 28 Apr 2023 20:26:17 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: rtl-optimization X-Bugzilla-Version: 13.0 X-Bugzilla-Keywords: missed-optimization X-Bugzilla-Severity: normal X-Bugzilla-Who: law at gcc dot gnu.org X-Bugzilla-Status: NEW X-Bugzilla-Resolution: X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 List-Id: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D109592 --- Comment #4 from Jeffrey A. Law --- If we need to handle subregs here, I would suggest something like this if (SUBREG_P (XEXP (op0, 0)) && subreg_lowpart_p (op0) ... other tests ... That way we know we're extracting the low word of the subreg. But I'm not = sure at all why we need to handle them in this code. I would expect generic optimizers to strip away the subregs in the result if they are extraneous. It's not clear why you check the size of the subreg modes. It seems like t= his optimization should work even for a paradoxical subreg (bitsize of inner wi= ll be smaller than bitsize of outer).=20=20 In general if you only have one statement in an arm of an IF-THEN-ELSE, the= n it need not be inside a { } block. Rather than using magic numbers like INTVAL (op1) + 8 =3D=3D 32 Instead use mode information. INTVAL (op) + GET_MODE_BITSIZE (QImode) =3D=3D GET_MODE_BITSIZE (SImode) // code for QI->SI expansion Then repeat for the other mode combinations. Note that we probably should go ahead and support QI->HI. While it doesn't happen for RISC-V, it could likely happen on other architectures. So you e= nd up wanting to supprot QI->HI, QI->SI QI->DI HI->SI, HI->DI SI->DI I don't know if it happens in practice, so check first to see what we do fo= r a zero extension variant of your original test. If we need to handle that to= o, it can be easily done by changing the shifts we recognize. Anyway, it looks like you're on the right track. I would suggest further discussions happen on gcc-patches. Anyway, it definitely looks like you're on the right track.=