From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 129128 invoked by alias); 6 Nov 2018 12:23:58 -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 129027 invoked by uid 89); 6 Nov 2018 12:23:57 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-0.9 required=5.0 tests=BAYES_00,KAM_LAZY_DOMAIN_SECURITY,KAM_SHORT autolearn=no version=3.3.2 spammy= X-HELO: foss.arm.com Received: from foss.arm.com (HELO foss.arm.com) (217.140.101.70) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 06 Nov 2018 12:23:55 +0000 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.72.51.249]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 8A15DA78; Tue, 6 Nov 2018 04:23:53 -0800 (PST) Received: from [10.2.206.82] (e109742-lin.cambridge.arm.com [10.2.206.82]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id F3E0B3F5CF; Tue, 6 Nov 2018 04:23:51 -0800 (PST) Subject: Re: [PATCH 2/2 v3][IRA,LRA] Fix PR86939, IRA incorrectly creates an interference between a pseudo register and a hard register To: Ramana Radhakrishnan Cc: Jeff Law , bergner@linux.ibm.com, Vladimir Makarov , Christophe Lyon , gcc-patches , Segher Boessenkool , Ramana Radhakrishnan , Kyrylo Tkachov References: <191bf9ee-98c4-b87e-cc65-40e1fb5de0ea@linux.ibm.com> <478a817c-719b-9c3c-5b38-de7b277d9f93@linux.ibm.com> <13a249ee-160b-2b28-151c-bed3faacbfc1@linux.ibm.com> <0363139a-01af-b0eb-0941-111c1d7395b5@redhat.com> <3cdd23c9-5d07-c26d-9a10-42a4a9d6f77a@foss.arm.com> <90073537-824d-697c-0ed8-9b611f9064c5@redhat.com> <57966a2f-6dfd-7f10-266e-2732d0df6874@foss.arm.com> From: Renlin Li Message-ID: Date: Tue, 06 Nov 2018 12:23:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-IsSubscribed: yes X-SW-Source: 2018-11/txt/msg00359.txt.bz2 Hi Ramana, On 11/06/2018 10:57 AM, Ramana Radhakrishnan wrote: > On Tue, Nov 6, 2018 at 10:52 AM Renlin Li wrote: >> >> Hi Jeff & Peter, >> >> On 11/05/2018 07:41 PM, Jeff Law wrote: >>> On 11/5/18 12:36 PM, Peter Bergner wrote: >>>> On 11/5/18 1:20 PM, Jeff Law wrote: >>>>> On 11/1/18 4:07 PM, Peter Bergner wrote: >>>>>> On 11/1/18 1:50 PM, Renlin Li wrote: >>>>>>> Is there any update on this issues? >>>>>>> arm-none-linux-gnueabihf native toolchain has been mis-compiled for a while. >>>>>> >>>>>> From the analysis I've done, my commit is just exposing latent issues >>>>>> in LRA. Can you try the patch I submitted here to see if it helps? >>>>>> >>>>>> https://gcc.gnu.org/ml/gcc-patches/2018-10/msg01757.html >>>>>> >>>>>> It survives on powerpc64le-linux, x86_64-linux and s390x-linux. >>>>>> Jeff threw it on his testers and said he saw an arm issue and was >>>>>> trying to come up with a test case for me to debug. >>>>> So I don't think the ARM issues are related to your patch, they may have >>>>> been related the combiner changes that went in around the same time. >> Yes, there are issues related to the combiner changes. > > But didn't the combiner changes come *after* these patches ? So IIUC, > Renlin has been trying to get these fixed *without* the combine > patches but just with your patch applied on top of the revision where > the problem started showing up . > > Can you confirm that Renlin ? I just did a bootstrap again with everything up to r264897 which is Oct 6. it produce the ICE I mentioned on the PR87899. The first combiner patch on Oct 22. Regards, Renlin > > > Ramana >> >> But the IRA/LRA change dose cause the arm-none-linux-gnueabihf bootstrap native toolchain mis-compiled. >> And the new patch seems not fix this problem. >> >> I am trying to extract a test case, but it is a little bit hard as the toolchain itself is mis-compiled. >> And it ICEs when compile test case with it. >> >> I created a bugzilla ticket for this, PR87899. >> >> ./gcc/cc1 ~/gcc/./gcc/testsuite/gcc.c-torture/execute/pr36034-1.c -O3 >> test main >> Analyzing compilation unit >> Performing interprocedural optimizations >> <*free_lang_data> Streaming LTO >> >> Assembling functions: >> testduring GIMPLE pass: ldist >> >> gcc/./gcc/testsuite/gcc.c-torture/execute/pr36034-1.c: In function ‘test’: >> gcc/./gcc/testsuite/gcc.c-torture/execute/pr36034-1.c:9:1: internal compiler error: Segmentation fault >> 9 | test (void) >> | ^~~~ >> 0x5c3a37 crash_signal >> ../../gcc/gcc/toplev.c:325 >> 0x63ef6b inchash::hash::add(void const*, unsigned int) >> ../../gcc/gcc/inchash.h:100 >> 0x63ef6b inchash::hash::add_ptr(void const*) >> ../../gcc/gcc/inchash.h:94 >> 0x63ef6b ddr_hasher::hash(data_dependence_relation const*) >> ../../gcc/gcc/tree-loop-distribution.c:143 >> 0x63ef6b hash_table::find_slot(data_dependence_relation* const&, insert_option) >> ../../gcc/gcc/hash-table.h:414 >> 0x63ef6b get_data_dependence >> ../../gcc/gcc/tree-loop-distribution.c:1184 >> 0x63f2bd data_dep_in_cycle_p >> ../../gcc/gcc/tree-loop-distribution.c:1210 >> 0x63f2bd update_type_for_merge >> ../../gcc/gcc/tree-loop-distribution.c:1255 >> 0x64064b build_rdg_partition_for_vertex >> ../../gcc/gcc/tree-loop-distribution.c:1302 >> 0x64064b rdg_build_partitions >> ../../gcc/gcc/tree-loop-distribution.c:1754 >> 0x64064b distribute_loop >> ../../gcc/gcc/tree-loop-distribution.c:2795 >> 0x642299 execute >> ../../gcc/gcc/tree-loop-distribution.c:3133 >> Please submit a full bug report, >> with preprocessed source if appropriate. >> Please include the complete backtrace with any bug report. >> See for instructions. >> >> >> >> Regards >> Renlin >> >> >> >>>>> >>>>> At this point your patch appears to be DTRT across the board. The only >>>>> fallout is the bogus s390 asm it caught in the kernel. >>>> >>>> Cool. I will note that I contacted the s390 kernel guys and gave them a >>>> fix to their broken constraints in that asm and they are going to fix it. >>> Sounds good. I've got a hack in my tester to "fix" that bogus asm until >>> the kernel folks do it right. >>> >>> >>>> >>>> Is the above an approval to commit the patch mentioned above or do you >>>> still want to wait until the ARM issues are fully resolved? >>> I think knowing the patch addresses all the known issues related to the >>> earlier IRA/LRA change unblocks the review step. I don't think we need >>> to wait for the other ARM issues to be resolved -- they seem to be >>> unrelated to the IRA/LRA changes. >>> >>> jeff >>>