From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 63524 invoked by alias); 14 Sep 2016 13:23:32 -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 63511 invoked by uid 89); 14 Sep 2016 13:23:30 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-4.0 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD autolearn=ham version=3.3.2 spammy=Hx-languages-length:935 X-HELO: gate.crashing.org Received: from gate.crashing.org (HELO gate.crashing.org) (63.228.1.57) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 14 Sep 2016 13:23:29 +0000 Received: from gate.crashing.org (localhost.localdomain [127.0.0.1]) by gate.crashing.org (8.14.1/8.13.8) with ESMTP id u8EDNQBq006525; Wed, 14 Sep 2016 08:23:27 -0500 Received: (from segher@localhost) by gate.crashing.org (8.14.1/8.14.1/Submit) id u8EDNQ3b006520; Wed, 14 Sep 2016 08:23:26 -0500 Date: Wed, 14 Sep 2016 13:28:00 -0000 From: Segher Boessenkool To: Jeff Law Cc: gcc-patches@gcc.gnu.org, bschmidt@redhat.com Subject: Re: [PATCH 6/9] sel-sched: Don't mess with register restores Message-ID: <20160914132326.GC4896@gate.crashing.org> References: <38963d815ea81b55d5b8e2ed85f2b347aad21395.1470015604.git.segher@kernel.crashing.org> <20160909211323.GA26965@gate.crashing.org> <8344f91b-8394-409b-78a9-e2c553713f45@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8344f91b-8394-409b-78a9-e2c553713f45@redhat.com> User-Agent: Mutt/1.4.2.3i X-IsSubscribed: yes X-SW-Source: 2016-09/txt/msg00825.txt.bz2 On Mon, Sep 12, 2016 at 11:24:01AM -0600, Jeff Law wrote: > >sel-sched-ir.c says > > > > /* Certain instructions cannot be cloned, and frame related insns and > > the insn adjacent to NOTE_INSN_EPILOGUE_BEG cannot be moved out of > > their block. */ > > if (prologue_epilogue_contains (insn)) > > > >... > > > >and I'm just extending that to "epilogue" instructions not in the > >"epilogue" ;-) > > > >If all such epilogue instructions always had a REG_CFA_RESTORE note, > >we could drop the "old" thing; but even instructions restoring a register > >do not always have such a note (they can be batched up, and they can be > >not emitted at all if not shrink-wrapping). > Can you fix this by registering the separate prologue/epilogue insns in > prologue_insn_hash and epilogue_insn_hash or does that have unintended > consequences? An interesting plan, I'll try. Segher