From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 70001 invoked by alias); 28 Mar 2016 17:42:10 -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 69980 invoked by uid 89); 28 Mar 2016 17:42:08 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.9 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=You've, Youve, rth, strengthen 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 (AES256-GCM-SHA384 encrypted) ESMTPS; Mon, 28 Mar 2016 17:41:58 +0000 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (Postfix) with ESMTPS id 4828F6437F; Mon, 28 Mar 2016 17:41:56 +0000 (UTC) Received: from bigtime.twiddle.net ([10.3.113.7]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u2SHftJl020792; Mon, 28 Mar 2016 13:41:55 -0400 Subject: Re: rs6000 stack_tie mishap again To: Alan Modra , Olivier Hainque References: <20160324041034.GB31470@bubble.grove.modra.org> Cc: GCC Patches From: Richard Henderson Message-ID: <56F96CE2.9020001@redhat.com> Date: Mon, 28 Mar 2016 19:58:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <20160324041034.GB31470@bubble.grove.modra.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2016-03/txt/msg01468.txt.bz2 On 03/23/2016 09:10 PM, Alan Modra wrote: > On Wed, Mar 23, 2016 at 05:04:39PM +0100, Olivier Hainque wrote: >> The reason why 894 is not accounted in the base ref computation is because it >> is part of the epilogue sequence, and init_alias_analysis has: >> >> /* Walk the insns adding values to the new_reg_base_value array. */ >> for (i = 0; i < rpo_cnt; i++) >> { ... >> if (could_be_prologue_epilogue >> && prologue_epilogue_contains (insn)) >> continue; >> >> The motivation for this is unclear to me. > > https://gcc.gnu.org/ml/gcc-patches/1999-08n/msg00048.html > >> My rough understanding is that we probably really care about frame_related >> insns only here, at least on targets where the flag is supposed to be set >> accurately. > > Also, possibly just prologue insns. So you might be able to modify > init_alias_analysis just to ignore the prologue and skip any need for > yet another hook. > > Let's see what rth thinks. He did say the patch might need to be > redone. :) > https://gcc.gnu.org/ml/gcc-patches/1999-08n/msg00072.html I be surprised if this is works as expected without side-effects. You've now exposed the restore of the frame pointer to alias analysis, and it's probably not seen as constant anymore. As you reference, I expect that any patch that opens the epilogue to such scrutiny is going to have to special-case the frame pointer as well. That said, as Segher points out later in the thread, one can arrange for hard regs within the body to bleed into temporaries used within the epilogue, which is bad. So perhaps this is exactly what's needed longer-term. More investigation is required. But I expect for stage4, the best solution is to strengthen the stack_tie pattern to block all memory. Early scheduling of the stack frame deallocation (a simple logic insn) can't really be that important to performance. r~