From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13539 invoked by alias); 27 Nov 2001 19:51:25 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 13492 invoked from network); 27 Nov 2001 19:51:23 -0000 Received: from unknown (HELO wf-rch.cirr.com) (24.7.109.109) by hostedprojects.ges.redhat.com with SMTP; 27 Nov 2001 19:51:23 -0000 Received: from acm.org (laptop [10.0.0.3]) by wf-rch.cirr.com (8.11.2/8.11.2/SuSE Linux 8.11.1-0.5) with ESMTP id fARJpKu01155; Tue, 27 Nov 2001 13:51:20 -0600 Message-ID: <3C03EF09.60009@acm.org> Date: Mon, 19 Nov 2001 05:36:00 -0000 From: Corey Minyard User-Agent: Mozilla/5.0 (X11; U; Linux ppc; en-US; rv:0.9.6) Gecko/20011121 X-Accept-Language: en-us MIME-Version: 1.0 To: Richard Henderson CC: gcc@gcc.gnu.org Subject: Re: Loop optimization bug with Ada front end on PPC (and probably Alpha) References: <3BFCA770.5070304@acm.org> <20011124124100.A2485@redhat.com> <3C0179C5.2090002@acm.org> <20011125175500.A11474@redhat.com> <3C0274ED.7000708@acm.org> <20011126134922.A24167@redhat.com> <3C02E95E.3010903@acm.org> <20011126231726.A29727@redhat.com> <3C03D700.3010205@acm.org> <20011127102856.A30042@redhat.com> Content-Type: multipart/mixed; boundary="------------070308070708010701080207" X-SW-Source: 2001-11/txt/msg00868.txt.bz2 This is a multi-part message in MIME format. --------------070308070708010701080207 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-length: 1135 Unforunately, this causes my original problem to come back. I'm nervous about this patch, too, I don't understand it at all. The loop where the problem occurred in the regression was reversed after this was done, but I turned off the reversal and it had the same problem. But it looks like the rest of the loop optimization code handles this (jumping over the first increment) situation correctly, the only problem occurrred in the doloop code. I tried moving this test to doloop_modify_runtime in doloop.c and adding the increment to the "diff" rtx in this situation, and it works in my simple testcase and didn't cause the problem in the regression. I haven't bootstrapped or run any tests yet, and I can't test the ia64 case with it. But I'll start a bootstrap now. -Corey Richard Henderson wrote: >I've got a hack that appears to work -- the start label >must be before the CONT marker. > >I'm nervous about this patch now, because I don't think >we really understand the exact situation in which the >original problem can ocurr. But as I've as yet got no >further failures to look at, I'll commit it anyway. > --------------070308070708010701080207 Content-Type: text/plain; name="gcc-ppc4.diff" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="gcc-ppc4.diff" Content-length: 1441 Index: doloop.c =================================================================== RCS file: /cvs/gcc/gcc/gcc/doloop.c,v retrieving revision 1.12 diff -u -p -r1.12 doloop.c --- doloop.c 2001/11/16 02:26:38 1.12 +++ doloop.c 2001/11/27 19:45:17 @@ -546,6 +546,8 @@ doloop_modify_runtime (loop, iterations_ rtx increment; int unsigned_p; enum rtx_code comparison_code; + struct loop_ivs *ivs = LOOP_IVS (loop); + struct iv_class *bl = REG_IV_CLASS (ivs, REGNO (loop_info->iteration_var)); increment = loop_info->increment; initial_value = loop_info->initial_value; @@ -595,6 +597,24 @@ doloop_modify_runtime (loop, iterations_ copy_rtx (neg_inc ? initial_value : final_value), copy_rtx (neg_inc ? final_value : initial_value), NULL_RTX, unsigned_p, OPTAB_LIB_WIDEN); + + if (loop->top + && reg_set_between_p (bl->biv->src_reg, loop->top, loop->scan_start)) + { + if (loop_dump_stream) + fprintf (loop_dump_stream, + "Loop iterations: Basic induction var skips initial incr.\n"); + if (GET_CODE (increment) != CONST_INT) + { + if (loop_dump_stream) + fprintf (loop_dump_stream, + "Loop iterations: Can't adjust with non-constant incr.\n"); + return 0; + } + diff = expand_simple_binop (GET_MODE (diff), PLUS, + diff, GEN_INT (INTVAL (increment)), + NULL_RTX, 1, OPTAB_LIB_WIDEN); + } if (abs_inc * loop_info->unroll_number != 1) { --------------070308070708010701080207-- From mboxrd@z Thu Jan 1 00:00:00 1970 From: Corey Minyard To: Richard Henderson Cc: gcc@gcc.gnu.org Subject: Re: Loop optimization bug with Ada front end on PPC (and probably Alpha) Date: Tue, 27 Nov 2001 11:51:00 -0000 Message-ID: <3C03EF09.60009@acm.org> References: <3BFCA770.5070304@acm.org> <20011124124100.A2485@redhat.com> <3C0179C5.2090002@acm.org> <20011125175500.A11474@redhat.com> <3C0274ED.7000708@acm.org> <20011126134922.A24167@redhat.com> <3C02E95E.3010903@acm.org> <20011126231726.A29727@redhat.com> <3C03D700.3010205@acm.org> <20011127102856.A30042@redhat.com> X-SW-Source: 2001-11/msg01369.html Message-ID: <20011127115100.I8nIjeZGJErxLa2aoFWBfaFQC-49VUu_8Ubv9YJPK9w@z> Unforunately, this causes my original problem to come back. I'm nervous about this patch, too, I don't understand it at all. The loop where the problem occurred in the regression was reversed after this was done, but I turned off the reversal and it had the same problem. But it looks like the rest of the loop optimization code handles this (jumping over the first increment) situation correctly, the only problem occurrred in the doloop code. I tried moving this test to doloop_modify_runtime in doloop.c and adding the increment to the "diff" rtx in this situation, and it works in my simple testcase and didn't cause the problem in the regression. I haven't bootstrapped or run any tests yet, and I can't test the ia64 case with it. But I'll start a bootstrap now. -Corey Richard Henderson wrote: >I've got a hack that appears to work -- the start label >must be before the CONT marker. > >I'm nervous about this patch now, because I don't think >we really understand the exact situation in which the >original problem can ocurr. But as I've as yet got no >further failures to look at, I'll commit it anyway. >