From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 103114 invoked by alias); 18 Apr 2016 13:44:29 -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 103103 invoked by uid 89); 18 Apr 2016 13:44:28 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.0 required=5.0 tests=AWL,BAYES_00,KAM_LAZY_DOMAIN_SECURITY,RCVD_IN_DNSWL_NONE,RP_MATCHES_RCVD autolearn=ham version=3.3.2 spammy=Hx-languages-length:1555, amonakovisprasru, amonakov@ispras.ru, D*ru X-HELO: smtp.ispras.ru Received: from smtp.ispras.ru (HELO smtp.ispras.ru) (83.149.199.79) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 18 Apr 2016 13:44:18 +0000 Received: from [10.10.3.121] (unknown [83.149.199.91]) by smtp.ispras.ru (Postfix) with ESMTP id E7AD9203E2; Mon, 18 Apr 2016 16:44:15 +0300 (MSK) Date: Mon, 18 Apr 2016 13:44:00 -0000 From: Alexander Monakov To: Ramana Radhakrishnan cc: Szabolcs Nagy , Andrew Pinski , Maxim Kuvyrkov , Li Bin , GCC Patches , Marcus Shawcroft , Richard Earnshaw , andrew.wafaa@arm.com, masami.hiramatsu.pt@hitachi.com, geoff@infradead.org, Takahiro Akashi , guohanjun@huawei.com, "Yangfei (Felix)" , jiangjiji@huawei.com, nd Subject: Re: [PATCH] [AArch64] support -mfentry feature for arm64 In-Reply-To: Message-ID: References: <1457943260-30894-1-git-send-email-huawei.libin@huawei.com> <570FBE14.10904@arm.com> User-Agent: Alpine 2.20 (LNX 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-SW-Source: 2016-04/txt/msg00846.txt.bz2 On Mon, 18 Apr 2016, Ramana Radhakrishnan wrote: > On Mon, Apr 18, 2016 at 2:26 PM, Alexander Monakov wrote: > > On Thu, 14 Apr 2016, Szabolcs Nagy wrote: > >> looking at [2] i don't see why > >> > >> func: > >> mov x9, x30 > >> bl _tracefunc > >> > >> > >> is not good for the kernel. > >> > >> mov x9, x30 is a nop at function entry, so in > >> theory 4 byte atomic write should be enough > >> to enable/disable tracing. > > > > Overwriting x9 can be problematic because GCC has gained the ability to track > > register usage interprocedurally: if foo() calls bar(), and GCC has already > > emitted code for bar() and knows that it cannot change x9, it can use that > > knowledge to avoid saving/restoring x9 in foo() around calls to bar(). See > > option '-fipa-ra'. > > > > If there's no register that can be safely used in place of x9 here, then > > the backend should emit the entry/pad appropriately (e.g. with an unspec that > > clobbers the possibly-overwritten register). > > Can you not use one of x16 / x17 the intra-procedure-call scratch > registers as per the PCS ? As long as: - there's a guarantee that the call to _tracefunc wouldn't need some kind of veneer that would clobber those; I don't know enough about AArch64 to say; - and GCC is not smart enough to be aware that intra-TU calls to 'func' (the function we're instrumenting) don't touch x16/x17. And GCC should be that smart, if it's not, it's a bug, right? :) Thanks. Alexander