From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11045 invoked by alias); 5 Dec 2009 16:18:56 -0000 Received: (qmail 11036 invoked by uid 22791); 5 Dec 2009 16:18:54 -0000 X-SWARE-Spam-Status: No, hits=-2.6 required=5.0 tests=BAYES_00,SPF_HELO_PASS,SPF_PASS X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Sat, 05 Dec 2009 16:18:49 +0000 Received: from int-mx04.intmail.prod.int.phx2.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.17]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id nB5GIl70024125 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 5 Dec 2009 11:18:48 -0500 Received: from [172.17.72.2] (ovpn01.gateway.prod.ext.phx2.redhat.com [10.5.9.1]) by int-mx04.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id nB5GIkRG029691; Sat, 5 Dec 2009 11:18:46 -0500 Message-ID: <4B1A87E5.1040102@redhat.com> Date: Sat, 05 Dec 2009 16:18:00 -0000 From: Jeff Law User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.4pre) Gecko/20090922 Fedora/3.0-3.9.b4.fc12 Thunderbird/3.0b4 MIME-Version: 1.0 To: daniel tian CC: gcc@gcc.gnu.org, peng.zheng@mavrixtech.com, yan.hu@mavrixtech.com.cn Subject: Re: Insn missing in Size optimization(-Os) References: <121fadb80912020218k6beb60aco49793e999091a747@mail.gmail.com> <121fadb80912020429w529cd9c5sd5c6db3f45f823f0@mail.gmail.com> <4B16A54D.2020600@redhat.com> <121fadb80912032301p6026675awc0168a8692087670@mail.gmail.com> <121fadb80912050001l6207eb45qb3ee83f9013ca8a1@mail.gmail.com> In-Reply-To: <121fadb80912050001l6207eb45qb3ee83f9013ca8a1@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org X-SW-Source: 2009-12/txt/msg00071.txt.bz2 On 12/05/09 01:01, daniel tian wrote: >> Yeah. The Move Symbol to R0 register is deleted, which is weird. >> And I still can not figure out why. Which means I still need to dig it. >> But I found when I used the gcc-4.0.2 version, the Call insn call the >> function direction >> call the function symbol which is OK. >> I mean how gcc determine to call the function directly with the function symbol >> or move the function symbol ref into a register then call the register. >> Obviously, now the gcc-4.3.0 in my porting is working in the latter one. >> >> > I found that gcc will choose to call symbol or register according a > TARGET MACRO -- > NO_FUNCTION_CSE. Here is the comment in internal document: > Define this macro if it is as good or better to call a constant > function address than to call an address kept in a register. > Right. When the cost of an indirect call is the same or greater than the cost of a direct call, then you should define NO_FUNCTION_CSE. Otherwise you would not define it. > Now I defined the macro, the bug disappears. But I still need to know > why gcc delete my insn. > Right. You've just papered over the problem. You need to debug reload and see whether or not the insn is ever emitted into the insn stream and if so when it gets deleted. You might start by monitoring emit_reload_insns's behavior when it handles your insn. jeff