From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26515 invoked by alias); 8 Dec 2009 04:04:47 -0000 Received: (qmail 26507 invoked by uid 22791); 8 Dec 2009 04:04:47 -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; Tue, 08 Dec 2009 04:04:42 +0000 Received: from int-mx02.intmail.prod.int.phx2.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id nB844e3q022326 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 7 Dec 2009 23:04:41 -0500 Received: from [172.17.72.2] (ovpn01.gateway.prod.ext.phx2.redhat.com [10.5.9.1]) by int-mx02.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id nB844cQE018143; Mon, 7 Dec 2009 23:04:39 -0500 Message-ID: <4B1DD056.8020906@redhat.com> Date: Tue, 08 Dec 2009 04:04: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> <4B1A87E5.1040102@redhat.com> <121fadb80912061910j59436c4en546e6eda7ee614fe@mail.gmail.com> In-Reply-To: <121fadb80912061910j59436c4en546e6eda7ee614fe@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/msg00094.txt.bz2 On 12/06/09 20:10, daniel tian wrote: >> You might start by monitoring emit_reload_insns's behavior when it handles >> your insn. >> > I just debug the source code with your advice. Check the function > emit_reload_insns. > > That insn was deleted before entering funcion emit_reload_insns. It > was deleted in reload(...) in reload1.c file just before calling > function reload_as_needed(this function will call emit_reload_insns). > It is sure that the insn is generated, but deleted after reload. > > insn was deleted in following code. > /* If a pseudo has no hard reg, delete the insns that made the equivalence. > If that insn didn't set the register (i.e., it copied the register to > memory), just delete that insn instead of the equivalencing insn plus > anything now dead. If we call delete_dead_insn on that insn, we may > delete the insn that actually sets the register if the register dies > there and that is incorrect. */ > No. I'm not referring to why the original insn was deleted. I'm referring to why the reload insn was deleted (or never emitted in the first place). Start by looking at the insns created by emit_reload_insns for the insn with the call. One of those should be loading a hard register with the function address. jeff