From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 46DF3383F84D; Tue, 12 May 2020 11:34:33 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 46DF3383F84D DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1589283273; bh=V7/LYBlxDqT1KHbWT9e0VqHV7epsfk0Sh+GSwVsA2JE=; h=From:To:Subject:Date:In-Reply-To:References:From; b=vGpgGtwNPZS/Z0sOkYJSctaJJB3U7Tg4BaGRJSx0YfijIyaV+b8UsBeqOIO5EQKA0 6aqJtDxPyoZ9u63MJ/MroKVYFCqCWJBL6SvFKtkUtRjUf0m2xZ9l8/KhYSUEHpJNBN YzlglIU5h33zHAb9WtRsvZ8+aiE1U22UkN3S/zkY= From: "rguenth at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug target/95078] Missing fwprop for SIB address Date: Tue, 12 May 2020 11:34:33 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: target X-Bugzilla-Version: 11.0 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: rguenth at gcc dot gnu.org X-Bugzilla-Status: UNCONFIRMED 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 X-BeenThere: gcc-bugs@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-bugs mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 May 2020 11:34:33 -0000 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D95078 --- Comment #1 from Richard Biener --- TER should go away, not be extended. So you are suggesting that we replace leaq 44(%rdi,%rdx,4), %rdx --- redundant could be fwprop movl (%rdx), %eax movl $3, (%rsi) addl (%rdx), %eax with movl 44(%rdi,%rdx,4), %eax movl $3, (%rsi) addl 44(%rdi,%rdx,4), %eax ? The variant that looks bigger is actually one byte smaller. Note as soon as there are three uses it will be larger again... So this is really something for RTL and yeah, fwprop only makes "local" decisions. Note that I think that your proposed variant will consume more resources since the complex addressing modes are likely split into a separate uop. Yes, overall I'd expect less latency for your sequence.=