From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 90228 invoked by alias); 3 Mar 2017 16:57:57 -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 89447 invoked by uid 89); 3 Mar 2017 16:57:57 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=conversations, literature, frequent X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 03 Mar 2017 16:57:56 +0000 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 45F9B61B91 for ; Fri, 3 Mar 2017 16:57:56 +0000 (UTC) Received: from [10.10.120.173] (ovpn-120-173.rdu2.redhat.com [10.10.120.173] (may be forged)) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id v23Gvt0c008222; Fri, 3 Mar 2017 11:57:55 -0500 Subject: Re: Fix (work around) LRA infinite loop, PR78911 To: Bernd Schmidt , GCC Patches References: From: Vladimir Makarov Message-ID: Date: Fri, 03 Mar 2017 16:57:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2017-03/txt/msg00185.txt.bz2 On 03/03/2017 08:36 AM, Bernd Schmidt wrote: > > Reload is designed in a way to avoid cycles and to process all reloads > for an insn in order of ascending class so as to avoid this kind of > issue. With LRA I'm really not sure how to fix this properly, but the > following patch seems to cure the PR at least, by recognizing when > we're about to spill a reload reg whose assigned class contains only > contains a single register. > I had conversations with several people who worked on different RAs and got a conclusion that looping is a pretty general problem in iterative classical RAs. Unfortunately, it is not discussed in a literature and ad-hoc approaches are used (that is why it is probably not discussed in scientific literature). On first stages of LRA development, looping was a very frequent bug and also add-hoc approaches were used to fix it. The major way is to predict that given decision can result in repeating patterns and to avoid such decision (e.g. lra_constraints.c::process_alt_operands contains code). Reasons for looping can have different nature and now I have no systematic solution on my mind to avoid all of them. > Bootstrapped and tested on x86_64-linux, ok? > > Yes. Thank you for working on this, Bernd. The issue mentioned in FIXME part of the comment can be addressed later if we have cases for which your fix will be not enough.