From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 36594 invoked by alias); 19 Oct 2016 22:42:38 -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 36582 invoked by uid 89); 19 Oct 2016 22:42:37 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.2 required=5.0 tests=BAYES_00,KAM_LAZY_DOMAIN_SECURITY,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=no version=3.3.2 spammy=Hx-languages-length:1574, HTo:D*com.cn, HTo:D*cn, Gang X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 19 Oct 2016 22:42:27 +0000 Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id AA6528123D; Wed, 19 Oct 2016 22:42:24 +0000 (UTC) Received: from localhost.localdomain (ovpn-116-87.phx2.redhat.com [10.3.116.87]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u9JMgMib002660; Wed, 19 Oct 2016 18:42:22 -0400 Subject: Re: [PATCH v3] gcc/config/tilegx/tilegx.c (tilegx_function_profiler): Save r10 to stack before call mcount To: Chen Gang References: <1465046750-3021-1-git-send-email-chengang@emindsoft.com.cn> <57F6573F.5010003@emindsoft.com.cn> Cc: rth@redhat.com, mikestump@comcast.net, gcc-patches@gcc.gnu.org, cmetcalf@ezchip.com, walt@tilera.com, peter.maydell@linaro.org, Chen Gang From: Jeff Law Message-ID: <6cafbf03-21ed-059c-4c4a-e9429ab3ad97@redhat.com> Date: Wed, 19 Oct 2016 22:42:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.3.0 MIME-Version: 1.0 In-Reply-To: <57F6573F.5010003@emindsoft.com.cn> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2016-10/txt/msg01587.txt.bz2 On 10/06/2016 07:53 AM, Chen Gang wrote: > Hello Maintainers: > > Is this patch OK? Please help check it when you have time (at least for > me, it passes all related test and comparation). > > And I shall continue to find and fix another issues about tilegx. > > Thanks. > > On 6/4/16 21:25, chengang@emindsoft.com.cn wrote: >> From: Chen Gang >> >> r10 may also be as parameter stack pointer for the nested function, so >> need save it before call mcount. >> >> Also clean up code: use '!' instead of "== 0" for checking >> static_chain_decl and compute_total_frame_size. >> >> 2016-06-04 Chen Gang >> >> gcc/ >> PR target/71331 >> * config/tilegx/tilegx.c (tilegx_function_profiler): Save r10 >> to stack before call mcount. >> (tilegx_can_use_return_insn_p): Clean up code. So if I understand the tilegx architecture correctly, you're issuing the r10 save & sp adjustment as a bundle, and the restore & sp adjustment as a bundle. The problem is the semantics of bunding on the tilegx effectively mean that all source operands are read in parallel, then all outputs occur in parallel. So if we take the bundle {addi sp,sp,-8 ; st sp, r10} The address used for the st is the value of the stack pointer before the addi instruction. Similarly for the restore r10 bundle. The address used for the load is sp before adjustment. Given my understanding of the tilegx bundling semantics, that seems wrong. Jeff