Return-Path: Delivered-To: apmail-harmony-dev-archive@www.apache.org Received: (qmail 31278 invoked from network); 17 Apr 2007 07:55:54 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 17 Apr 2007 07:55:54 -0000 Received: (qmail 78413 invoked by uid 500); 17 Apr 2007 07:55:57 -0000 Delivered-To: apmail-harmony-dev-archive@harmony.apache.org Received: (qmail 78392 invoked by uid 500); 17 Apr 2007 07:55:57 -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 78383 invoked by uid 99); 17 Apr 2007 07:55:57 -0000 Received: from herse.apache.org (HELO herse.apache.org) (140.211.11.133) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 17 Apr 2007 00:55:57 -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 (herse.apache.org: domain of mike.fursov@gmail.com designates 64.233.184.231 as permitted sender) Received: from [64.233.184.231] (HELO wr-out-0506.google.com) (64.233.184.231) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 17 Apr 2007 00:55:50 -0700 Received: by wr-out-0506.google.com with SMTP id i31so1818678wra for ; Tue, 17 Apr 2007 00:55:29 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; b=Ly32iLF/IVjiZj7EyrDM8PHoNLMzjyKBuFZO9Ap3MBTIaFEYUrcF8d2rgYk6DoDLhoOYuWyHUUH88Jt96NSvWeN1AsnzLtcXLnjYItoW6X5mvZqxee7Rsk1EPS+JeoqK+SExi+6UZNZbZsvgHuRYEkTuVAhpzdD7l2KyteIH/7g= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; b=DqRqz9+ZoelgqmdfzkqQvES1+vxSumdCjBw8jO7Vp0tR4w0vRaP6tR/tYOQaGTTQQKfrzWgcslWhQMeOAGhCuQ1Qdt35Q5kvD8GMAPVgrdIvbnUm5fhsdeJU3TJ5fOann+8ywjcsvltRiCTg6tTGQ1836DAYO/AaP8gQVKseyI0= Received: by 10.115.14.1 with SMTP id r1mr2296971wai.1176796528901; Tue, 17 Apr 2007 00:55:28 -0700 (PDT) Received: by 10.115.95.12 with HTTP; Tue, 17 Apr 2007 00:55:28 -0700 (PDT) Message-ID: Date: Tue, 17 Apr 2007 14:55:28 +0700 From: "Mikhail Fursov" To: dev@harmony.apache.org Subject: Re: [drvm][jit] ABCD does not eliminate upper bound check In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_55470_5088795.1176796528831" References: <2DEC434D-8BC6-4BF4-8DD6-1E3A1A6C6671@uiuc.edu> X-Virus-Checked: Checked by ClamAV on apache.org ------=_Part_55470_5088795.1176796528831 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Some advices: 1) update and rebuild classlib first (ant clean/svn update/ant fetch-depends/ant) 2) run 'build clean' before building updated drlvm to be sure that there are no object files left for removed sources. On 4/17/07, Maksim Ananjev wrote: > > I am now fully convinced that there is a problem on my side. I tried > applying the patch as you had described - got segmentation fault on my > test execution. I suppose, that's because i have rather old build. > > I tried to make "svn up" - but got compilation errors in the porting > layer. > > Maybe i need some time to claw through these troubles :) > > > 2007/4/17, Naveen Neelakantam : > > The new ABCD implementation works on the example code you posted. > > > > Perhaps the patch did not apply correctly? I noticed that you said > > you unzipped vm.zip before applying abcd_update_1_full.patch, which > > isn't the way that the patch is intended to be used (sorry for the > > confusion, my fault). > > > > All you need to do is apply the abcd_update_1_full.patch, you should > > not unzip vm.zip. This command should do the trick (from the svn root): > > >patch -p0 < abcd_update_1_full.patch > > > > If you are still having problems, please tar (or zip) up the > > following: your log files, the java test source, your emconf file. > > Then post the tar (or zip) on the HARMONY-1788 jira along with the > > svn revision you are using, OS, etc. > > > > Naveen > > > > On Apr 16, 2007, at 1:25 PM, Maksim Ananjev wrote: > > > > > I've placed "classic_abcd" after the ssa construction: > > > > > > - > > > XDjit.CS_OPT.path.optimizer=ssa,classic_abcd,devirt,inline,uce,purge,s > > > implify,dce,uce, > > > lazyexc,memopt,simplify,dce,uce,lower,dessa,statprof,markglobals > > > > > > Nothing changed :-( > > > > > > > > > > > > 2007/4/17, Maksim Ananjev : > > >> Naveen, > > >> > > >> Here is a part of my opt.emconf file which states an order of > > >> optimization passes on HIR: > > >> > > >> - > > >> XDjit.CS_OPT.path.optimizer=ssa,devirt,inline,uce,purge,simplify,dce, > > >> uce, > > >> classic_abcd,lazyexc,memopt,simplify,dce,uce,lower,dessa,statprof,mar > > >> kglobals > > >> > > >> > > >> 2007/4/17, Naveen Neelakantam : > > >> > I can take a look, but I suspect that the problem is caused by the > > >> > loop peeling pass. > > >> > > > >> > Can you post your modified emconf file? Or can you tell me which > > >> > passes you inserted classic_abcd between? > > >> > > > >> > Thanks, > > >> > Naveen > > >> > > > >> > On Apr 16, 2007, at 12:39 PM, Maksim Ananjev wrote: > > >> > > > >> > > Hi! > > >> > > > > >> > > I tried to apply new ABCD optimization path to the following > > >> code: > > >> > > > > >> > > int[] array = new int[10]; > > >> > > int l = array.length; > > >> > > for(int i =0; i > >> > > { > > >> > > array[i] = i; > > >> > > } > > >> > > > > >> > > However the bounds check on the assignment inside the loop was > > >> not > > >> > > eliminated. > > >> > > > > >> > > I used the patches from here: > > >> > > https://issues.apache.org/jira/browse/HARMONY-1788 > > >> > > > > >> > > I unzipped files in vm.zip and added them in > > >> > > jitrino/src/optimizer/abcd/ folder. Then I applied > > >> > > abcd_update_1_full.patch. Then I added "classic_abcd" to > > >> opt.emconf > > >> > > > > >> > > But according to log file upper bound check cannot be proved > > >> > > redundant. That's strange because this case looks rather obvious. > > >> > > > > >> > > May be I did something wrong in applying the patch? Or ABCD > > >> really > > >> > > cannot deal with such case? > > >> > > > > >> > > -- > > >> > > Maksim > > >> > > > >> > > > >> > > >> > > >> -- > > >> Maksim > > >> > > > > > > > > > -- > > > Maksim > > > > > > > -- > Maksim > -- Mikhail Fursov ------=_Part_55470_5088795.1176796528831--