From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3208 invoked by alias); 10 Feb 2005 18:02:19 -0000 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org Received: (qmail 2535 invoked by alias); 10 Feb 2005 18:01:45 -0000 Date: Thu, 10 Feb 2005 20:53:00 -0000 Message-ID: <20050210180145.2534.qmail@sourceware.org> From: "law at redhat dot com" To: gcc-bugs@gcc.gnu.org In-Reply-To: <20041219105831.19078.chris@bubblescope.net> References: <20041219105831.19078.chris@bubblescope.net> Reply-To: gcc-bugzilla@gcc.gnu.org Subject: [Bug rtl-optimization/19078] [4.0 Regression] Poor quality code after loop unrolling. X-Bugzilla-Reason: CC X-SW-Source: 2005-02/txt/msg00886.txt.bz2 List-Id: ------- Additional Comments From law at redhat dot com 2005-02-10 18:01 ------- Subject: Re: [4.0 Regression] Poor quality code after loop unrolling. On Thu, 2005-02-10 at 12:12 +0100, Zdenek Dvorak wrote: > > In comment #3 Zdenek said "Possibly even better would be to add generation of > > autoincrements to loop optimizer, but this would require fixing cse so that it > > handles them correctly." Zdenek, can you elaborate on why CSE needs fixing? > > cse does not handle autoincrements. I have no idea what's the problem > there, it is just what I was told when I asked for the possibility to > move the autoinc creation pass last time. Anyone has more precise > information about the nature of the problem? It's been about a decade since I looked at cse vs autoincrements, so the details have faded from memory. [The original context I found the problem was in an attempt to run cse after reload. ] Anyway, from a 30 second look at CSE the first thing that jumps out at me is I don't think we would invalidate objects in the hash table which are auto-incremented. Jeff -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19078