From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id EE95E3858C5F; Fri, 8 Dec 2023 17:01:29 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org EE95E3858C5F DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1702054889; bh=h34CdcJ33YoBacSOXye9+IApfTsa/gnSiQALXorh+F8=; h=From:To:Subject:Date:In-Reply-To:References:From; b=hvBp5W+gGpLbzWT429XVvMj45lbVX8S0jKG32k6VXJCiX6X5DQRuogAp8CKewY222 kP/P5O+PfRBqKTkHmFP9bwWv4D4HW0kv6R93dTjuVpXzhO93kfm6iqKTLM6+1Q+X8+ RUkyy23pgEJamQxSYG1xGy5g8DWGxFdwVqP9F8qA= From: "jakub at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug rtl-optimization/112758] [13/14 Regression] Inconsistent Bitwise AND Operation Result between int and long long int Date: Fri, 08 Dec 2023 17:01:22 +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: 14.0 X-Bugzilla-Keywords: needs-bisection, wrong-code X-Bugzilla-Severity: normal X-Bugzilla-Who: jakub 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: 13.3 X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc 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=3D112758 Jakub Jelinek changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |ebotcazou at gcc dot gnu.o= rg, | |jakub at gcc dot gnu.org, | |law at gcc dot gnu.org, | |segher at gcc dot gnu.org --- Comment #3 from Jakub Jelinek --- Seems expand_compound_operation is called on (sign_extend:DI (mem/c:SI (lo_sum:DI (reg/f:DI 144) (symbol_ref:DI ("globalVar") [flags 0x86] )) [1 globalVar+0 S4 A32])) and takes the 7336 tem =3D gen_lowpart (mode, XEXP (x, 0)); 7337 if (!tem || GET_CODE (tem) =3D=3D CLOBBER) 7338 return x; 7339 tem =3D simplify_shift_const (NULL_RTX, ASHIFT, mode, 7340 tem, modewidth - pos - len); 7341 tem =3D simplify_shift_const (NULL_RTX, unsignedp ? LSHIFTRT : ASHIFTRT, 7342 mode, tem, modewidth - len); path on it, mode being DImode, modewidth 64, pos 0, len 32. The second simplify_shift_const is then called with (ashift:DI (subreg:DI (mem/c:SI (lo_sum:DI (reg/f:DI 144) (symbol_ref:DI ("globalVar") [flags 0x86] )) [1 globalVar+0 S4 A32]) 0) (const_int 32 [0x20])) and triggers the 10810 /* If this was (ashiftrt (ashift foo C1) C2) and FOO = has more 10811 than C1 high-order bits equal to the sign bit, we = can convert 10812 this to either an ASHIFT or an ASHIFTRT depending = on the 10813 two counts. 10814=20=20=20 10815 We cannot do this if VAROP's mode is not SHIFT_UNIT_MODE. */ 10816=20=20=20 10817 if (code =3D=3D ASHIFTRT && first_code =3D=3D ASHIFT 10818 && int_varop_mode =3D=3D shift_unit_mode 10819 && (num_sign_bit_copies (XEXP (varop, 0), shift_unit_mode) 10820 > first_count)) 10821 { 10822 varop =3D XEXP (varop, 0); 10823 count -=3D first_count; 10824 if (count < 0) 10825 { 10826 count =3D -count; 10827 code =3D ASHIFT; 10828 } 10829=20=20=20 10830 continue; 10831 } optimization in there. As RISC V is WORD_REGISTER_OPERATIONS target with load_extend_op (E_SImode)= =3D=3D SIGN_EXTEND, it triggers the: 5444 /* For paradoxical SUBREGs on machines where all register operations 5445 affect the entire register, just look inside. Note th= at we are 5446 passing MODE to the recursive call, so the number of s= ign bit 5447 copies will remain relative to that mode, not the inner mode. 5448=20=20=20=20 5449 This works only if loads sign extend. Otherwise, if we get a 5450 reload for the inner part, it may be loaded from the stack, and 5451 then we lose all sign bit copies that existed before t= he store 5452 to the stack. */ 5453 if (WORD_REGISTER_OPERATIONS 5454 && load_extend_op (inner_mode) =3D=3D SIGN_EXTEND 5455 && paradoxical_subreg_p (x) 5456 && MEM_P (SUBREG_REG (x))) 5457 return cached_num_sign_bit_copies (SUBREG_REG (x), mode, 5458 known_x, known_mode, known_ret); path and so the sign-extension in the end folds into just a paradoxical sub= reg of the MEM. But probably something in the combiner then just sees a paradoxical SUBREG and thinks that all the bits above the SUBREG_REG are undefined and picks ZERO_EXTEND. I'm afraid I don't know enough about WORD_REGISTER_OPERATIONS to know what = is right and what is not.=