From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4584 invoked by alias); 12 Sep 2016 17:01:55 -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 4567 invoked by uid 89); 12 Sep 2016 17:01:54 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-4.2 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=horrible, held, his, person 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; Mon, 12 Sep 2016 17:01:53 +0000 Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (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 75EBBC04B309; Mon, 12 Sep 2016 17:01:52 +0000 (UTC) Received: from localhost.localdomain (ovpn-116-111.phx2.redhat.com [10.3.116.111]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u8CH1pA4022577; Mon, 12 Sep 2016 13:01:51 -0400 Subject: Re: [PATCH 5/9] regrename: Don't run if function was separately shrink-wrapped To: David Edelsohn References: <7e74a019-d477-348f-2dc6-744e1db38f2f@redhat.com> <20160909204107.GC21356@gate.crashing.org> <14ff3e40-4c2c-7e8b-b822-07ff3575b771@redhat.com> <20160910064052.GA7255@gate.crashing.org> <32231187-0fa2-815d-ab89-7e3d15b646d4@redhat.com> Cc: Segher Boessenkool , GCC Patches , Bernd Schmidt From: Jeff Law Message-ID: Date: Mon, 12 Sep 2016 17:04:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.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: 2016-09/txt/msg00647.txt.bz2 On 09/12/2016 10:54 AM, David Edelsohn wrote: > On Sep 12, 2016 17:33, "Jeff Law" > wrote: >> >> On 09/10/2016 12:40 AM, Segher Boessenkool wrote: >>> >>> On Fri, Sep 09, 2016 at 05:01:19PM -0600, Jeff Law wrote: >>>> >>>> On 09/09/2016 02:41 PM, Segher Boessenkool wrote: >>>>> >>>>> On Fri, Sep 09, 2016 at 12:31:31PM -0600, Jeff Law wrote: >>>>>> >>>>>> On 06/08/2016 03:18 AM, Bernd Schmidt wrote: >>>>>>> >>>>>>> On 06/08/2016 03:47 AM, Segher Boessenkool wrote: >>>>>>>> >>>>>>>> + /* regrename creates wrong code for exception handling, > if used >>>>>>>> together >>>>>>>> + with separate shrink-wrapping. Disable for now, until > we have >>>>>>>> + figured out what exactly is going on. */ >>>>>>> >>>>>>> >>>>>>> That needs to be figured out now or it'll be there forever. >>>>>> >>>>>> I suspect it's related to liveness computations getting > out-of-wack with >>>>>> separate shrink wrapping. If that's the case, then the question in my >>>>>> mind is how painful is this going to be to fix in the df scanning > code. >>>>> >>>>> >>>>> I haven't been able to pin-point the failure. It happens for just > a few >>>>> huge testcases. So I am hoping someone who understands regrename will >>>>> figure it out. >>>> >>>> I think that's likely going to fall onto you :-) We don't generally >>>> allow passes to just get disabled because some other pass causes them to >>>> generate the wrong code. >>> >>> >>> We can instead declare that anyone enabling regrename is on his own? >>> I like that plan better. >> >> No. I won't ack that. It seems totally backwards. >> >> >>> >>> I can also make the compiler error out if you try to have both separate >>> shrink-wrapping and regrename on at the same time. >>> >>> There are no happy answers :-( >> >> The answer is to debug the problem, and yes it may be painful. I'd > probably start by fixing the dataflow issues and see if that fixes the > regrename thing as a side effect. >> >> >>> >>>> Though I'm curious how you triggered this -- regrename isn't enabled by >>>> default (except for that brief window earlier this year...). >>> >>> >>> Yes, these patches are that old now already. I also enabled regrename >>> by default for quite a while, for testing purposes, since at the time >>> it looked like regrename would be on by default for most architectures. >>> Separate shrink-wrapping is supposed to be useful for all ports, not >>> just for Power. >> >> I think enabling regrename by default is the right thing to do long term. > > Jeff, > > The current regrename pass is horrible. Badly designed, badly written > and ineffective. You are the only person who likes it. ?!? I don't like or dislike it. I think it solves a well known problem for processors with particular pipeline characteristics. No more, no less. > > There are plenty of gcc passes that don't work well together. If segher > can work around it easily, okay. This series of patches should not be > held up because of a bug in a badly written pass that is not enabled by > default and only found by segher being extra diligent. It's not a question of not working well together. It's a case where the two in combination generate incorrect code and we don't know if it's a regrename issue or an issue with Segher's code. I have some suspicions here, but until Segher does the analysis, I can't ack the patch. jeff