From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 123382 invoked by alias); 17 Oct 2019 21:55:49 -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 123374 invoked by uid 89); 17 Oct 2019 21:55:49 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.1 spammy= X-HELO: mail-vs1-f67.google.com Received: from mail-vs1-f67.google.com (HELO mail-vs1-f67.google.com) (209.85.217.67) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 17 Oct 2019 21:55:47 +0000 Received: by mail-vs1-f67.google.com with SMTP id p13so2692763vso.0 for ; Thu, 17 Oct 2019 14:55:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sifive.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=EWAhrC31T0N6K8kr9cphhoyvxqVMMMVUu1a7+F9bKGk=; b=f2rHh5a2pIx5pGrFqHS5Ku9ExooEU1YFyGvixLHkh+xCcnwz05H2ppv78jkI0bbZYv 0j1TDYyi1uj4a8XENh+ERAdTAwCGLnpG/lq4ma1O4qnfIEvnjQ5iloGQHd4d2MSl12jj t0+51S1ehgc+pild+3nU6TTMU7Qe5D31dr4uQosp9/vr1oaNbq/FF07EPZQQeRX9Lxo3 eAwymxXfpxPWX0DQREOPq7Sx5qOC754SBdyKT4gVgoDbFedAUDVRISxqzOrPhFbeBGNJ Y+29rl6LWCPlUcRHI/xv18pbNw2SXsbKOUlTmugI461cLvSKxHA9n1FW3aU6+u4q3RkN tsow== MIME-Version: 1.0 References: <20191016210445.20232-1-jimw@sifive.com> <20191017140920.GZ4962@embecosm.com> In-Reply-To: <20191017140920.GZ4962@embecosm.com> From: Jim Wilson Date: Thu, 17 Oct 2019 22:05:00 -0000 Message-ID: Subject: Re: [PATCH] RISC-V: Include more registers in SIBCALL_REGS. To: Andrew Burgess Cc: GCC Patches Content-Type: text/plain; charset="UTF-8" X-IsSubscribed: yes X-SW-Source: 2019-10/txt/msg01325.txt.bz2 On Thu, Oct 17, 2019 at 7:09 AM Andrew Burgess wrote: > I'm still working on part 2, I'm hoping to have a revised patch posted > by Monday next week. I started looking at the part 2 patch also. I noticed a problem where the NOTE_INSN_EPILOGUE_BEGIN can occur before the NOTE_INSN_PROLOGUE_END due to branch and basic block optimizations, I get an ICE in this case due to deref of a null pointer. This is pretty easy to fix, I just added a check to riscv_remove_unneeded_save_restore_calls in the loop that searches for NOTE_INSN_PROLOGUE_END, and if I find NOTE_INSN_EPILOGUE_BEGIN first I exit without doing anything. A more complex fix would be to try to follow the CFG instead of scanning forward from the prologue end note to find the epilogue begin note. I also noticed a case where the __riscv_save_0 call was optimized away but the __riscv_restore_0 call was not. In this case the function has two epilogues, and only one of the two epilogues was optimized. We could just check for more than one epilogue and return without doing any work as the simple fix. Or a more complex fix is to try to handle more than one epilogue. Given the kinds of problems I'm seeing, I think there should be an option to control this optimization, so people can turn it off is necessary. I think it is OK if this is on by default if it passes the gcc testsuite. Since you are looking at this, I can look at something else for a few days. I was just trying to get this off of my backlog. Jim