From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 737383858C33; Mon, 16 Oct 2023 17:35:45 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 737383858C33 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1697477745; bh=sAHvITlINp/S4dz4dnqqwesUC13TneT3ZKJpyIsAUR8=; h=From:To:Subject:Date:In-Reply-To:References:From; b=NCPN4H8VQ0llXsMiqlzbwQWvBMoBq9z7soZasv3JsTHY6J55i60qClBQmwWVKopUG 9qHfsHRuCCRim5v8jLVxUIW5wEihHejAOo5A9Lo9rfPn5p139EsHnH2k8Y8KIpwul4 Z9KaL43/02w9U3uN5V+BBOecijI+WqyLeQh4BKGs= From: "pinskia at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug rtl-optimization/111835] Suboptimal codegen: zero extended load instead of sign extended one Date: Mon, 16 Oct 2023 17:35:44 +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: unknown X-Bugzilla-Keywords: missed-optimization X-Bugzilla-Severity: enhancement X-Bugzilla-Who: pinskia 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: cf_reconfirmed_on component everconfirmed bug_severity bug_status cf_gcctarget keywords 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=3D111835 Andrew Pinski changed: What |Removed |Added ---------------------------------------------------------------------------- Last reconfirmed| |2023-10-16 Component|middle-end |rtl-optimization Ever confirmed|0 |1 Severity|normal |enhancement Status|UNCONFIRMED |NEW Target| |aarch64 Keywords| |missed-optimization --- Comment #1 from Andrew Pinski --- So as you said it depends on the target. Most non-x86 target have: /* Define if loading from memory in MODE, an integral mode narrower than BITS_PER_WORD will either zero-extend or sign-extend. The value of this macro should be the code that says which one of the two operations is implicitly done, or UNKNOWN if none. */ #define LOAD_EXTEND_OP(MODE) ZERO_EXTEND defined. Which causes REE to be confused before hand: Before REE: (insn 7 10 9 2 (set (reg:SI 0 x0 [orig:92 _1 ] [92]) (zero_extend:SI (mem:QI (reg:DI 0 x0 [99]) [0 *src_3(D)+0 S1 A8]))) "/app/example.cpp":4:39 146 {*zero_extendqisi2_aarch64} (nil)) (insn 9 7 15 2 (set (mem:QI (reg:DI 1 x1 [100]) [0 *dst_5(D)+0 S1 A8]) (reg:QI 0 x0 [orig:92 _1 ] [92])) "/app/example.cpp":5:10 62 {*movqi_aarch64} (nil)) (insn 15 9 16 2 (set (reg/i:SI 0 x0) (sign_extend:SI (reg:QI 0 x0 [orig:92 _1 ] [92]))) "/app/example.cpp":7:1 142 {*extendqisi2_aarch64} (nil)) Which means that REE does not elimite it. Note on x86 we get before REE: (insn 7 4 8 2 (set (reg:QI 0 ax [orig:98 _1 ] [98]) (mem:QI (reg:DI 5 di [104]) [0 *src_3(D)+0 S1 A8])) "/app/example.cpp":4:39 93 {*movqi_internal} (nil)) (insn 8 7 9 2 (set (mem:QI (reg:DI 4 si [105]) [0 *dst_5(D)+0 S1 A8]) (reg:QI 0 ax [orig:98 _1 ] [98])) "/app/example.cpp":5:10 93 {*movqi_internal} (nil)) (insn 9 8 15 2 (set (reg:SI 0 ax [orig:103 _1 ] [103]) (sign_extend:SI (reg:QI 0 ax [orig:98 _1 ] [98]))) "/app/example.cpp":6:12 183 {extendqisi2} (nil)) So REE is able to move that sign extend back to the original load.=