From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lj1-x231.google.com (mail-lj1-x231.google.com [IPv6:2a00:1450:4864:20::231]) by sourceware.org (Postfix) with ESMTPS id 4D1D9385841E for ; Thu, 22 Jun 2023 07:40:30 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 4D1D9385841E Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-lj1-x231.google.com with SMTP id 38308e7fff4ca-2b477e9d396so62488101fa.3 for ; Thu, 22 Jun 2023 00:40:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1687419629; x=1690011629; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=bGGXV6EMGT7Y+C07jAwmpkYl2WUMHvZdlBDaEbpxq0k=; b=jCopcWTZ0B6iCvz+n93sn2vMJ8ZVhLjmrFpdcLNcUJkedfNp2jcTxR9hut6ozZG9yD R/pfpFmFXh6jm1eIk8GOl30LrnzyElBUOI/yKItK5vhbwOmrUorFPZ9cdQFRifBabLNd Lvgq0eEjuZ1suqlQqFSdo8y+diT3buG8M/nJXM3QX1UBzni4WK4S7UujnsciHRAOvlmj LL8PRn5xlqUzH/ObvOD3Qw6QAhip7IlmlutNrm4CDzvlL3urfmORRG1vWJLN9XpY0BPp zxgXhRZDscO8CHJtYh8u+bwzTeZg+4O54yPPq5kcXTylEHx59nuKRKXX0PosOmT9pQbT N3dw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1687419629; x=1690011629; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=bGGXV6EMGT7Y+C07jAwmpkYl2WUMHvZdlBDaEbpxq0k=; b=TWA9vyO61lQM+ZVpAyJq8hfkoHPHMM72Nb/65A0sCxBa1DP66pSwlzS8CoXzUX5kk9 kmsCqorRwJO7WhRF9sZ2fBKEQuR9p508ARk7AifI5wNCMUU65gRbl1VEhluDxX43iC6B hlAMcHM1XuSpQlGaRdRn+HKY3xXEGdkenUZulFvw3uWrcJIBapa4+nJgfUMPXySDFThx aTq9RHR0qB6zDZ/xYVfc0fNekmaLHObnR74z8mWfIEMpQBXYM1atYGTQR6jw9q6tXpdG ko292fhAVT8SWnmz4nTNJGTohQTbc4UD3Qs2aqx6ANzUQ8z5DGOsEwmNgXkaw6SUY2KY ptog== X-Gm-Message-State: AC+VfDxzEmIcP47SBr3qGee+b13Dt/Ih/FOZGTWBmUQ2t0beFsALD4xK rChMvIsP+nf6+NX2KHWGaBrWVHIRI/CmenEkLLE= X-Google-Smtp-Source: ACHHUZ7UyjmwViR7x8KkUzl1kQixsobf5vKfVBVh7w+h3H4QguoGnWQ4Qcx980Sn+TA1ivIoP3ko00sQjy8Iy7E+Ciw= X-Received: by 2002:a2e:8908:0:b0:2b4:6f70:c393 with SMTP id d8-20020a2e8908000000b002b46f70c393mr10322270lji.20.1687419628696; Thu, 22 Jun 2023 00:40:28 -0700 (PDT) MIME-Version: 1.0 References: <20230525123550.1072506-1-manolis.tsamis@vrull.eu> <20230525123550.1072506-3-manolis.tsamis@vrull.eu> <5836d561-2986-484c-8d9a-744c948e8602@gmail.com> <87ttv3xud1.fsf@linaro.org> <3bdd7695-ad88-d8d9-5133-05cb95623949@gmail.com> <1a3e4d1e-59ee-c3ef-fd0b-d4d9265dc12d@gmail.com> <871qi4idr7.fsf@linaro.org> In-Reply-To: <871qi4idr7.fsf@linaro.org> From: Richard Biener Date: Thu, 22 Jun 2023 09:37:30 +0200 Message-ID: Subject: Re: [PATCH 2/2] cprop_hardreg: Enable propagation of the stack pointer if possible. To: Thiago Jung Bauermann Cc: Jeff Law , Tamar Christina , Andrew Pinski , Manolis Tsamis , Philipp Tomsich , Palmer Dabbelt , Kito Cheng , "gcc-patches@gcc.gnu.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-1.4 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,KAM_SHORT,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE autolearn=ham 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 Thu, Jun 22, 2023 at 1:42=E2=80=AFAM Thiago Jung Bauermann wrote: > > > Hello, > > Jeff Law writes: > > > On 6/19/23 22:52, Tamar Christina wrote: > > > >>> It's a bit hackish, but could we reject the stack pointer for operand= 1 in the > >>> stack-tie? And if we do so, does it help? > >> Yeah this one I had to defer until later this week to look at closer b= ecause what I'm > >> wondering about is whether the optimization should apply to frame rela= ted > >> RTX as well. > >> Looking at the description of RTX_FRAME_RELATED_P that this optimizati= on may > >> end up de-optimizing RISC targets by creating an offset that is larger= than offset > >> which can be used from a SP making reload having to spill. i.e. somet= imes the > >> move was explicitly done. So perhaps it should not apply it to > >> RTX_FRAME_RELATED_P in find_oldest_value_reg and copyprop_hardreg_forw= ard_1? > >> Other parts of this pass already seems to bail out in similar situatio= ns. So I needed > >> to > >> write some testcases to check what would happen in these cases hence t= he deferral. > >> to later in the week. > > Rejecting for RTX_FRAME_RELATED_P would seem reasonable and probably be= tter in general to > > me. The cases where we're looking to clean things up aren't really in = the > > prologue/epilogue, but instead in the main body after register eliminat= ion has turned fp > > into sp + offset, thus making all kinds of things no longer valid. > > The problems I reported were fixed by commits: > > 580b74a79146 "aarch64: Robustify stack tie handling" > 079f31c55318 "aarch64: Fix gcc.target/aarch64/sve/pcs failures" > > Thanks! > > But unfortunately I'm still seeing bootstrap failures (ICE segmentation > fault) in today's trunk with build config bootstrap-lto in both > armv8l-linux-gnueabihf and aarch64-linux-gnu. If there's not yet a bugreport for this please make sure to open one so this issue doesn't get lost. > If I revert commit 6a2e8dcbbd4b "cprop_hardreg: Enable propagation of > the stack pointer if possible" from trunk then both bootstraps succeed. > > Here's the command I'm using to build on armv8l: > > ~/src/configure \ > SHELL=3D/bin/bash \ > --with-gnu-as \ > --with-gnu-ld \ > --disable-libmudflap \ > --enable-lto \ > --enable-shared \ > --without-included-gettext \ > --enable-nls \ > --with-system-zlib \ > --disable-sjlj-exceptions \ > --enable-gnu-unique-object \ > --enable-linker-build-id \ > --disable-libstdcxx-pch \ > --enable-c99 \ > --enable-clocale=3Dgnu \ > --enable-libstdcxx-debug \ > --enable-long-long \ > --with-cloog=3Dno \ > --with-ppl=3Dno \ > --with-isl=3Dno \ > --disable-multilib \ > --with-float=3Dhard \ > --with-fpu=3Dneon-fp-armv8 \ > --with-mode=3Dthumb \ > --with-arch=3Darmv8-a \ > --enable-threads=3Dposix \ > --enable-multiarch \ > --enable-libstdcxx-time=3Dyes \ > --enable-gnu-indirect-function \ > --disable-werror \ > --enable-checking=3Dyes \ > --enable-bootstrap \ > --with-build-config=3Dbootstrap-lto \ > --enable-languages=3Dc,c++,fortran,lto \ > && make \ > profiledbootstrap \ > SHELL=3D/bin/bash \ > -w \ > -j 40 \ > CFLAGS_FOR_BUILD=3D"-pipe -g -O2" \ > CXXFLAGS_FOR_BUILD=3D"-pipe -g -O2" \ > LDFLAGS_FOR_BUILD=3D"-static-libgcc" \ > MAKEINFOFLAGS=3D--force \ > BUILD_INFO=3D"" \ > MAKEINFO=3Decho > > And here's the slightly different one for aarch64-linux: > > ~/src/configure \ > SHELL=3D/bin/bash \ > --with-gnu-as \ > --with-gnu-ld \ > --disable-libmudflap \ > --enable-lto \ > --enable-shared \ > --without-included-gettext \ > --enable-nls \ > --with-system-zlib \ > --disable-sjlj-exceptions \ > --enable-gnu-unique-object \ > --enable-linker-build-id \ > --disable-libstdcxx-pch \ > --enable-c99 \ > --enable-clocale=3Dgnu \ > --enable-libstdcxx-debug \ > --enable-long-long \ > --with-cloog=3Dno \ > --with-ppl=3Dno \ > --with-isl=3Dno \ > --disable-multilib \ > --enable-fix-cortex-a53-835769 \ > --enable-fix-cortex-a53-843419 \ > --with-arch=3Darmv8-a \ > --enable-threads=3Dposix \ > --enable-multiarch \ > --enable-libstdcxx-time=3Dyes \ > --enable-gnu-indirect-function \ > --disable-werror \ > --enable-checking=3Dyes \ > --enable-bootstrap \ > --with-build-config=3Dbootstrap-lto \ > --enable-languages=3Dc,c++,fortran,lto \ > && make \ > profiledbootstrap \ > SHELL=3D/bin/bash \ > -w \ > -j 40 \ > LDFLAGS_FOR_TARGET=3D"-Wl,-fix-cortex-a53-843419" \ > CFLAGS_FOR_BUILD=3D"-pipe -g -O2" \ > CXXFLAGS_FOR_BUILD=3D"-pipe -g -O2" \ > LDFLAGS_FOR_BUILD=3D"-static-libgcc" \ > MAKEINFOFLAGS=3D--force \ > BUILD_INFO=3D"" \ > MAKEINFO=3Decho > > -- > Thiago