From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10975 invoked by alias); 2 Sep 2019 16:12:47 -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 10967 invoked by uid 89); 2 Sep 2019 16:12:46 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-4.1 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.3.1 spammy=as, rm, rr, clobber X-HELO: foss.arm.com Received: from foss.arm.com (HELO foss.arm.com) (217.140.110.172) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 02 Sep 2019 16:12:45 +0000 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 2DB19344; Mon, 2 Sep 2019 09:12:44 -0700 (PDT) Received: from localhost (e121540-lin.manchester.arm.com [10.32.99.62]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id AC9753F59C; Mon, 2 Sep 2019 09:12:43 -0700 (PDT) From: Richard Sandiford To: Christophe Lyon Mail-Followup-To: Christophe Lyon ,, richard.sandiford@arm.com Cc: Subject: Re: [ARM/FDPIC v5 04/21] [ARM] FDPIC: Add support for FDPIC for arm architecture References: <20190515124006.25840-1-christophe.lyon@st.com> <20190515124006.25840-5-christophe.lyon@st.com> Date: Mon, 02 Sep 2019 16:12:00 -0000 In-Reply-To: (Christophe Lyon's message of "Thu, 29 Aug 2019 17:34:15 +0200") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-IsSubscribed: yes X-SW-Source: 2019-09/txt/msg00067.txt.bz2 Sorry for the slow reply. Christophe Lyon writes: > On 16/07/2019 13:58, Richard Sandiford wrote: >> Christophe Lyon writes: >>> +(define_insn "*restore_pic_register_after_call" >>> + [(parallel [(unspec [(match_operand:SI 0 "s_register_operand" "=r,r") >>> + (match_operand:SI 1 "nonimmediate_operand" "r,m")] >>> + UNSPEC_PIC_RESTORE) >>> + (use (match_dup 1)) >>> + (clobber (match_dup 0))]) >>> + ] >>> + "" >>> + "@ >>> + mov\t%0, %1 >>> + ldr\t%0, %1" >>> +) >>> + >>> (define_expand "call_internal" >>> [(parallel [(call (match_operand 0 "memory_operand" "") >>> (match_operand 1 "general_operand" "")) >> >> Since operand 0 is significant after the instruction, I think this >> should be: >> >> (define_insn "*restore_pic_register_after_call" >> [(set (match_operand:SI 0 "s_register_operand" "+r,r") >> (unspec:SI [(match_dup 0) >> (match_operand:SI 1 "nonimmediate_operand" "r,m")] >> UNSPEC_PIC_RESTORE))] >> ... >> >> The (use (match_dup 1)) looks redundant, since the unspec itself >> uses operand 1. >> > When I try that, I have cases where the restore instruction is discarded, when the call happens just before function return. Since r9 is caller-saved, it should be restored but after dse2 the dumps say: > (insn (set (reg:SI 9 r9) > (unspec:SI [ > (reg:SI 9 r9) > (reg:SI 4 r4 [121]) > ] UNSPEC_PIC_RESTORE)) > (expr_list:REG_UNUSED (reg:SI 9 r9) (nil)))) > > and this is later removed by cprop_hardreg (which says the exit block uses r4, sp, and lr: should I make it use r9?) But if it's caller-saved (i.e. call-clobbered), function A shouldn't need to restore r9 after a call unless A needs the value of r9 for something. I.e. A shouldn't need to restore r9 for A's own caller, because the caller should be doing that iself. So if r9 is caller-saved and not referenced between the call and function exit, deleting the restore sounds like the right thing to do. Richard