From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 62463 invoked by alias); 29 Oct 2016 04:26:35 -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 62448 invoked by uid 89); 29 Oct 2016 04:26:34 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.6 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,SPF_PASS,UNPARSEABLE_RELAY autolearn=ham version=3.3.2 spammy=duty, H*Ad:D*comcast.net, H*Ad:U*rth, Gang X-HELO: out28-169.mail.aliyun.com Received: from out28-169.mail.aliyun.com (HELO out28-169.mail.aliyun.com) (115.124.28.169) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Sat, 29 Oct 2016 04:26:30 +0000 X-Alimail-AntiSpam:AC=CONTINUE;BC=0.07459764|-1;FP=0|0|0|0|0|-1|-1|-1;HT=e02c03295;MF=chengang@emindsoft.com.cn;NM=1;PH=DS;RN=9;RT=9;SR=0;TI=SMTPD_---.76shSkD_1477715176; Received: from ShengShiZhuChengdeMacBook-Pro.local(mailfrom:chengang@emindsoft.com.cn ip:223.72.70.67) by smtp.aliyun-inc.com(10.147.42.135); Sat, 29 Oct 2016 12:26:17 +0800 Message-ID: <581426D0.2000900@emindsoft.com.cn> Date: Sat, 29 Oct 2016 04:26:00 -0000 From: Chen Gang User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Jeff Law , Bernd Edlinger , Chris Metcalf CC: "gcc-patches@gcc.gnu.org" , Richard Henderson , Mike Stump , Walter Lee , "peter.maydell@linaro.org" , Chen Gang Subject: Re: [PATCH v3] gcc/config/tilegx/tilegx.c (tilegx_function_profiler): Save r10 to stack before call mcount References: <6e750e23-8a13-4bde-2c50-6fa6d34240d9@redhat.com> In-Reply-To: <6e750e23-8a13-4bde-2c50-6fa6d34240d9@redhat.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-SW-Source: 2016-10/txt/msg02397.txt.bz2 Firstly, sorry for replying late (During these days, I worked overtime every workday, and have to reply in weekend). On 10/24/16 23:27, Jeff Law wrote: > On 10/23/2016 12:11 PM, Bernd Edlinger wrote: >> Hi, >> >> I don't know much about tilegx, but >> I think the patch should work as is. >> >> This is because the >> Save r10 code is a bundle >> >> { >> addi sp, sp, -8 >> st sp, r10 >> } >> >> which stores r10 at [sp] and subtracts 8 from sp. >> >> The restore r10 code is actually two bundles: > Thanks for pointing that out! I totally missed the restore was two bundles. > > >> >> addi sp, sp, 8 >> ld r10, sp >> >> This just adds 8 to sp, and loads r10 from there. > Right. And with the restore as two bundles the semantics of the save/restore seem consistent/correct. > Oh, really. Sorry that I almost forgot my history about this patch. Originally, I sent patch v1 both with 2 bundles, but when I sent patch v2, I let "saving r10" within a bundle for optimization (I mentioned about it in replying patch v1 on 2016-05-31). >> >> I don't know how __mcount is implemented, it must >> be some asm code, almost all functions save the >> lr at [sp] when invoked, but I don't know if __mcount >> does that at all, if it doesn't do that, then the >> adjusting of sp might be unnecessary. >> >> The only thing that might be a problem is that >> the stack is always adjusted in multiples of 16 >> on the tilegx platform, see tilegx.h: >> >> #define STACK_BOUNDARY 128 >> >> That is counted in bits, and means 16 bytes. >> But your patch adjusts the stack only by 8. > Missed that. Without knowing the tile ports, I can't say with any degree of confidence that it's safe to only adjust by 8 bytes. Adjusting by 16 seems safer. > Oh, really! After check all the output code, "addi sp" operation are all times of 16!! So I guess, I shall addi sp 16, too (send patch v4 for it, if no any addition reply within a week). >> >> Furthermore, I don't see how the stack unwinding will work >> with this stack adjustment when no .cfi directives >> are emitted, but that is probably not a big problem. > I wouldn't be surprised if the tilegx isn't the only port with this problem. I don't think we've ever been good about making sure the unwinders are correct for targets where we profile before the prologue and which emit the profiling bits directly rather than representing them as RTL. > Excuse me, I have no any idea about it (in fact, in honest, I guess, I am still not quite familiar with gcc development in details). At present, what I can know is: after this patch, gcc can pass various related unwinding test (including nested functions) under qemu tilegx linux-user (originally, I traced related insns, they should be ok). :-) Thanks. -- Chen Gang (陈刚) Managing Natural Environments is the Duty of Human Beings.