Return-Path: Delivered-To: apmail-harmony-commits-archive@www.apache.org Received: (qmail 1318 invoked from network); 27 Nov 2007 10:33:07 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 27 Nov 2007 10:33:07 -0000 Received: (qmail 599 invoked by uid 500); 27 Nov 2007 10:32:55 -0000 Delivered-To: apmail-harmony-commits-archive@harmony.apache.org Received: (qmail 283 invoked by uid 500); 27 Nov 2007 10:32:54 -0000 Mailing-List: contact commits-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 commits@harmony.apache.org Received: (qmail 265 invoked by uid 99); 27 Nov 2007 10:32:54 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 27 Nov 2007 02:32:54 -0800 X-ASF-Spam-Status: No, hits=-100.0 required=10.0 tests=ALL_TRUSTED X-Spam-Check-By: apache.org Received: from [140.211.11.4] (HELO brutus.apache.org) (140.211.11.4) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 27 Nov 2007 10:33:04 +0000 Received: from brutus (localhost [127.0.0.1]) by brutus.apache.org (Postfix) with ESMTP id 6D6C971420E for ; Tue, 27 Nov 2007 02:32:43 -0800 (PST) Message-ID: <615712.1196159563444.JavaMail.jira@brutus> Date: Tue, 27 Nov 2007 02:32:43 -0800 (PST) From: "Egor Pasko (JIRA)" To: commits@harmony.apache.org Subject: [jira] Commented: (HARMONY-2170) [drlvm][jit] Suggestion of new Range Check elimination optimization. MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org [ https://issues.apache.org/jira/browse/HARMONY-2170?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12545784 ] Egor Pasko commented on HARMONY-2170: ------------------------------------- Evgueni, 1. why didn't you eliminate FastArrayFilling at all? does it give any boost over your loop with eliminated bounds checks? 2. why do you call it dynamic ABCD? the transformation you describe is a standard "loop versioning" (known paper) 3. looking at your patch, you are actually eliminating the bounds checks. Why? this _is_ the job of classic_abcd and it should make it better. Just invoke it after peeling. The (3) is especially hurting me because I see no point in implementing yet another BoundsCheck elimination while you can use more general classic_abcd for that. If it does not work in your case, just let me know the example. I will fire up debugging it. BTW, sorry for not replying very soon. The JIRA notification has slipped somewhere between the cracks :) > [drlvm][jit] Suggestion of new Range Check elimination optimization. > -------------------------------------------------------------------- > > Key: HARMONY-2170 > URL: https://issues.apache.org/jira/browse/HARMONY-2170 > Project: Harmony > Issue Type: Improvement > Components: DRLVM > Environment: All. > Reporter: Sergey Kuksenko > Assignee: Mikhail Fursov > Attachments: abcde2.patch, dabce.patch, dabce.patch > > > Currently [drlvm][jit] contains ABCD (range check elimination) algorithm. > ABCD algorithm works pretty well if iterations over an array is perfomed with array.length access. > However, there are a set of code patterns where ABCD algorithm won't work. > For example, java.util classes ArrayList, Vector, HashMap, etc... very often contains a field where a real upper bound is stored (and usually this upped bound is less then array.legth). So, iteration over such arrays usually is performed by the following way: > for (int i = 0; i < real_length; i++) { > array[i].... > } > Where "real_length" is a field which contains real upper bound. > Very often it is too expensive or impossible for JIT to determine value range for this field and in such ways (when cycle limit is value obtained outside method) ABCD range check elimination can't work. > Suggestion: > In case of cycle like: > int i=0; > while(i < real_length) { > checkRange(array, i); // introduce explicit range check operation > ...array[i]... > i++; > } > Split this cycle to: > int i=0; > while(i < min(real_length, array.length) ) { > ...array[i]... // NO range check here > i++; > } > while(i checkRange(array, i); > ...array[i]... > i++; > } > After such splitting range check is useless at the first cycle and may be removed. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.