Return-Path: Delivered-To: apmail-harmony-dev-archive@www.apache.org Received: (qmail 66533 invoked from network); 12 Mar 2008 09:18:47 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 12 Mar 2008 09:18:47 -0000 Received: (qmail 40796 invoked by uid 500); 12 Mar 2008 09:18:43 -0000 Delivered-To: apmail-harmony-dev-archive@harmony.apache.org Received: (qmail 40473 invoked by uid 500); 12 Mar 2008 09:18:42 -0000 Mailing-List: contact dev-help@harmony.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@harmony.apache.org Delivered-To: mailing list dev@harmony.apache.org Received: (qmail 40463 invoked by uid 99); 12 Mar 2008 09:18:42 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 12 Mar 2008 02:18:42 -0700 X-ASF-Spam-Status: No, hits=2.0 required=10.0 tests=HTML_MESSAGE,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of nkurtov@gmail.com designates 72.14.204.232 as permitted sender) Received: from [72.14.204.232] (HELO qb-out-0506.google.com) (72.14.204.232) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 12 Mar 2008 09:18:06 +0000 Received: by qb-out-0506.google.com with SMTP id e6so2441048qbe.2 for ; Wed, 12 Mar 2008 02:18:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; bh=5SVtLpXsnerixodMQOKhMzDdpBT/f85Zc+oGJGGH3Mk=; b=YjzACDDjf3WagkiOffSyqcHev7igRYnWHV9Dhnm+onPvKggIL8yHzvJA1Bnm2nfAl6CZ6jz6AA57eBFDAYNTEqdFPmOBbGg3l2CdPntVM6DSaHIIa4l7ciesVnh3n8BKfx442P2fIVdOZdO/hxZcvGInHL2N57DVtVPzNf6uGaI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; b=hyiYkNs002KUS+udX/0nEyCwGBoZp3XfRxX49xPoMxgUOLZDPUsnPkaUQpgmuzCGVMG1XgJIx5ji3BMz0T8Yjt2gm3zlSiPwwAW0Fe9MMpdWjdmpSOgRP+6aReLTZc3LpEEZ/tYtSqTUbJaitXWYgUdZvuRUC9Eo1atcuiSyKV0= Received: by 10.142.90.16 with SMTP id n16mr3245312wfb.70.1205313496278; Wed, 12 Mar 2008 02:18:16 -0700 (PDT) Received: by 10.142.11.16 with HTTP; Wed, 12 Mar 2008 02:18:16 -0700 (PDT) Message-ID: <5b0732b20803120218j1998fdc3r28e6984547424e65@mail.gmail.com> Date: Wed, 12 Mar 2008 15:18:16 +0600 From: "Nikolay Kurtov" To: dev@harmony.apache.org Subject: Re: [drlvm][jitrino]Difference in bc-mapping after translator In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_4876_27994735.1205313496269" References: <5b0732b20803111229j3a787d6di602436c3d2ec46aa@mail.gmail.com> <5b0732b20803120111u3d0349bek40b21743e8da73c1@mail.gmail.com> X-Virus-Checked: Checked by ClamAV on apache.org ------=_Part_4876_27994735.1205313496269 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline JIRA issue created https://issues.apache.org/jira/browse/HARMONY-5595 2008/3/12, Mikhail Fursov : > > Looks like the reason is that LabelInst gets its offset in IRBuilder only > after next HIR inst is added to the block. > In this case we see that ILOAD_0 is not represented as HIR inst, so > LabelInst gets its offset from the second inst. > This is bug in translator. > > The most simple fix is to move LabelInst bc-offset update from > Inst* IRBuilder::appendInst(Inst* inst) { > to > void IRBuilder::setBcOffset(uint32 bcOffset) > > Anyway I think this problem is worth creating a JIRA issue. > > > > > > On Wed, Mar 12, 2008 at 2:11 PM, Nikolay Kurtov wrote: > > > Here is the method's code > > > > public static byte func(byte val) { > > byte result = 1; > > switch (val) { > > case 0: > > for (int i = 0; i < 54321; i++) { > > result += i; > > } > > break; > > case 1: > > result = (byte) (val + 45); > > break; > > case 4: > > result = (byte) (val + 21); > > break; > > default: > > result--; > > break; > > } > > if (result < 30) { > > result <<= 1; > > } else { > > result /= 2; > > } > > return result; > > } > > > > 2008/3/12, Mikhail Fursov : > > > > > > Nikolay, could you post a Java method here to reproduce the issue? > > > > > > > > > On Wed, Mar 12, 2008 at 1:29 AM, Nikolay Kurtov > > wrote: > > > > > > > I compiled the same class with JET and OPT, and found a difference > in > > > > bytecode-mapping > > > > > > > > One of branches of switch goes to this code: > > > > ;; 58) ILOAD_0 > > > > ;; 59) BIPUSH 45 > > > > ;; 61) IADD > > > > ;; 62) I2B > > > > ;; 63) ISTORE_1 > > > > .... > > > > So, after the recompilation by OPT, the block should begin from > > bcOffset > > > > 58 > > > > > > > > In OPT after translator I found in irdump the following block > > > > Block L5: > > > > Predecessors: ENTRY_L0 > > > > Successors: L8 > > > > I5:L5: bcmap:59 > > > > I34:ldci4 #45 -) t14:int32 > > > > I35:add t1, t14 -) t15:int32 > > > > I36:convi1 t15 -) t16:int32 > > > > I37:stvar t16 -) v1:int32 > > > > .... > > > > > > > > The block begins from bcOffset 59 > > > > I consider these values in JET and OPT should be equal. > > > > Is it a bug? > > > > > > > > Now I'm exploring the code of JavaByteCodeTranslator and IRBuilder > but > > > > cannot figure out the cause of problem > > > > Can you advise me how to fix it? > > > > > > > > -- > > > > Regards, > > > > Nikolay > > > > > > > > mailto: nkurtov@gmail.com > > > > > > > > > > > > > > > > > > > -- > > > > > > Mikhail Fursov > > > > > > > > > > > -- > > Regards, > > Nikolay > > > > mailto: nkurtov@gmail.com > > > > > > > -- > > Mikhail Fursov > -- Regards, Nikolay mailto: nkurtov@gmail.com ------=_Part_4876_27994735.1205313496269--