From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22531 invoked by alias); 15 Aug 2011 09:40:02 -0000 Received: (qmail 22488 invoked by uid 22791); 15 Aug 2011 09:40:00 -0000 X-SWARE-Spam-Status: No, hits=-7.1 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_HI,RP_MATCHES_RCVD,SPF_HELO_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; Mon, 15 Aug 2011 09:39:44 +0000 Received: from int-mx12.intmail.prod.int.phx2.redhat.com (int-mx12.intmail.prod.int.phx2.redhat.com [10.5.11.25]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id p7F9dh3d015160 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Mon, 15 Aug 2011 05:39:43 -0400 Received: from zebedee.pink (ovpn-116-31.ams2.redhat.com [10.36.116.31]) by int-mx12.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id p7F9dfd6027303; Mon, 15 Aug 2011 05:39:42 -0400 Message-ID: <4E48E95C.4080206@redhat.com> Date: Mon, 15 Aug 2011 09:40:00 -0000 From: Andrew Haley User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.18) Gecko/20110621 Fedora/3.1.11-1.fc14 Thunderbird/3.1.11 MIME-Version: 1.0 To: java@gcc.gnu.org Subject: Re: Why does a 'new' statement produce so many temporary variables References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact java-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: java-owner@gcc.gnu.org X-SW-Source: 2011-08/txt/msg00005.txt.bz2 On 08/09/2011 08:18 AM, Li junsong wrote: > Hi, > > I am writing a plugin to add a pass in gcc 4.6.1. the pass will do > some optimizations before high gimple lowering, > moving some gimple nodes from one place to another. In cc1, the gimple > code is quite > understandable. But I'm confused by the gimple that Java front end converts to. > > I dump the file, here is a piece of code doing "new". > > #ref#2#4 = _Jv_AllocObjectNoFinalizer (&Number.class$$); > #ref#3#6 = #ref#2#4; > #ref#2#4 = #ref#3#6; > D.459 = #slot#1#1; > #slot#4#7 = D.459; > #ref#3#6.1 = #ref#3#6; > (#ref#3#6.1, #slot#4#7); > > the corresponding Java source code is > > int sum = 4; > Number number; > if ( sum < 100 ) > number = new Number(sum); <=here > > the Number class is a simple one: > > class Number > { > int i; > Number(int inputi){ > i = inputi; > } > } > > Here comes my question: > 1. I am wondering why we don't use 'NEW_EXPR' to represent a "new" statement? > The 'NEW_EXPR' has already been defined in the cp-tree.def.( As I know, the > "new" statement in cp front end is also represented as that in > Java front end, > which is "gimple_call" in gimple code, "ADDR_EXPR" in tree code, > is it? why?) Why would we want to use 'NEW_EXPR' ? We simply call the allocator which creates the object. > 2. How can I figure out which pieces of code are corresponding > to 'NEW' statement? ( Can I always first find the > "_Jv_AllocObjectNoFinalize" or "_Jv_AllocObject" > gimple_call and then "" gimple_call to locate the code?) I think so. > 3. I find that there is no document to describe the implementation of > Java front end. > I don't understand why we need so many temporary variables: > > #ref#2#4 = _Jv_AllocObjectNoFinalizer (&Number.class$$); > #ref#3#6 = #ref#2#4; > #ref#2#4 = #ref#3#6; > > Here, the #ref#3#6 and #ref#2#4 is a kind waste. But each "new" statement > does the same thing. It's not really a waste: we assume that the optimizer will delete useless temporaries, and as far as I know it does. Andrew.