From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12016 invoked by alias); 10 Nov 2015 22:33:12 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 11354 invoked by uid 89); 10 Nov 2015 22:33:11 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-3.1 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW,RP_MATCHES_RCVD,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mailapp01.imgtec.com Received: from mailapp01.imgtec.com (HELO mailapp01.imgtec.com) (195.59.15.196) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 10 Nov 2015 22:33:10 +0000 Received: from hhmail02.hh.imgtec.org (unknown [10.100.10.20]) by Websense Email Security Gateway with ESMTPS id 1402F7D4A8363; Tue, 10 Nov 2015 22:33:03 +0000 (GMT) Received: from HHMAIL01.hh.imgtec.org (10.100.10.19) by hhmail02.hh.imgtec.org (10.100.10.20) with Microsoft SMTP Server (TLS) id 14.3.235.1; Tue, 10 Nov 2015 22:33:06 +0000 Received: from hhmail02.hh.imgtec.org ([::1]) by HHMAIL01.hh.imgtec.org ([fe80::710b:f219:72bc:e0b3%28]) with mapi id 14.03.0235.001; Tue, 10 Nov 2015 22:33:06 +0000 From: Robert Suchanek To: James Greenhalgh , Christophe Lyon CC: Bernd Schmidt , "ebotcazou@adacore.com" , "gcc-patches@gcc.gnu.org" Subject: RE: [RFC][PATCH] Preferred rename register in regrename pass Date: Tue, 10 Nov 2015 22:33:00 -0000 Message-ID: References: <55FC2B8D.6000106@redhat.com> <56179FC6.3040503@redhat.com> <5640CA1E.3070205@redhat.com> ,<20151110174252.GA33923@arm.com> In-Reply-To: <20151110174252.GA33923@arm.com> Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-IsSubscribed: yes X-SW-Source: 2015-11/txt/msg01297.txt.bz2 Hi all, > > Now that 'make check' has had enough time to run, I can see several > > regressions in the configurations where GCC still builds. > > For more details: > > http://people.linaro.org/~christophe.lyon/cross-validation/gcc/trunk/23= 0087/report-build-info.html > > >=20 > This also causes failures for AArch64 -mcpu=3Dcortex-a57 targets. This > testcase: >=20 > void > foo (unsigned char *out, const unsigned char *in, int a) > { > for (int i =3D 0; i < a; i++) > { > out[0] =3D in[2]; > out[1] =3D in[1]; > out[2] =3D in[0]; > in +=3D 3; > out +=3D 3; > } > } >=20 > Fails as so: >=20 > foo.c: In function 'void foo(unsigned char*, const unsigned char*, int)= ': > foo.c:12:1: internal compiler error: in scan_rtx_reg, at regrename.c:10= 74 > } > ^ >=20 > 0xbe00f8 scan_rtx_reg > ..../gcc/regrename.c:1073 > 0xbe0ad5 scan_rtx > ..../gcc/regrename.c:1401 > 0xbe1038 record_out_operands > ..../gcc/regrename.c:1554 > 0xbe1f50 build_def_use > ..../gcc/regrename.c:1802 > 0xbe1f50 regrename_analyze(bitmap_head*) > ..../gcc/regrename.c:726 > 0xf7a0c7 func_fma_steering::execute_fma_steering() > ..../gcc/config/aarch64/cortex-a57-fma-steering.c:1026 > 0xf7a9c1 pass_fma_steering::execute(function*) > ..../gcc/config/aarch64/cortex-a57-fma-steering.c:1063 > Please submit a full bug report, > with preprocessed source if appropriate. > Please include the complete backtrace with any bug report. > See for instructions. >=20 > When compiled with: >=20 > -O3 -mcpu=3Dcortex-a57 foo.c >=20 > Thanks, > James 0xbe1f50 build_def_use > ..../gcc/regrename.c:1802 > 0xbe1f50 regrename_analyze(bitmap_head*) > ..../gcc/regrename.c:726 > 0xf7a0c7 func_fma_steering::execute_fma_steering() > ..../gcc/config/aarch64/cortex-a57-fma-steering.c:1026 > 0xf7a9c1 pass_fma_steering::execute(function*) > ..../gcc/config/aarch64/cortex-a57-fma-steering.c:1063 > Please submit a full bug report, > with preprocessed source if appropriate. > Please include the complete backtrace with any bug report. > See for instructions. >=20 > When compiled with: >=20 > -O3 -mcpu=3Dcortex-a57 foo.c Thanks for the test case. It appears that I managed to run only those tests that didn't expose the assertion error and there is at least one more port i.e. powerpc64 showing similar ICEs when -funroll-loops and/or -fpeel-loops are used that enables the regrename pass. In both AArch64 and ARM cases I found the same insufficient checks when chains are tied and it seems that this is the root cause behind all failures. With the attached patch I built arm-none-linux-gnueabi without failures, checked a number of cases shown on Christophe's page, the above test case, and it would appear that the problem is solved. The reason behind the failures is that the terminated_this_insn had a different number of consecutive registers (and mode) to the input operand in a move currently being considered for tying. In the fix, I allow tying only if there is matching number of NREGS. Bernd, do you think that this check would be sufficient and safe? I'm not sure what would be better: check the mode, nregs plus perhaps consider tying only if nregs =3D=3D 1. Regards, Robert gcc/ * regname.c (scan_rtx_reg): Check the matching number of consecutive registers when tying chains. --- gcc/regrename.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/gcc/regrename.c b/gcc/regrename.c index d727dd9..0b8f032 100644 --- a/gcc/regrename.c +++ b/gcc/regrename.c @@ -1068,7 +1068,9 @@ scan_rtx_reg (rtx_insn *insn, rtx *loc, enum reg_clas= s cl, enum scan_actions act && GET_CODE (pat) =3D=3D SET && GET_CODE (SET_DEST (pat)) =3D=3D REG && GET_CODE (SET_SRC (pat)) =3D=3D REG - && terminated_this_insn) + && terminated_this_insn + && terminated_this_insn->nregs + =3D=3D REG_NREGS (recog_data.operand[1])) { gcc_assert (terminated_this_insn->regno =3D=3D REGNO (recog_data.operand[1])); --=20 2.4.5