This is the mail archive of the
mailing list for the GCC project.
Re: PATCH for bogus loop optimization
- To: mark at markmitchell dot com
- Subject: Re: PATCH for bogus loop optimization
- From: Jeffrey A Law <law at cygnus dot com>
- Date: Fri, 17 Jul 1998 00:56:01 -0600
- cc: egcs-patches at cygnus dot com
- Reply-To: law at cygnus dot com
In message <199807161735.KAA02596@smtp.earthlink.net>you write:
> I've been working on some improvements to loop. In particular, I've
> got code that I'll submit soon that puts memory references into
> pseudos for the duration of the loop. This makes lots of loops go
I'd be interested in hearing about these. Particularly since the same
thing can be achived on a wider scale by hooking the alias analysis code
into the GCSE/PRE pass of the compiler.
The trick is proper definition of what operations constitute an evaluation
of an expression and what operations kill the expression. Once you do
that (using alias analysis) you feed the bitmaps into the PRE code and
you get back globally optimal locations for your loads and stores.
Morgan's book has a reasonable discussion of this topic.
Anyway, back to the topic at hand.
I understand what's going on. Ugh. What a pain.
Is there some reason why we don't go ahead and change the comparison?
We know that insn is the cc0 setter, so the cc0 user (the comparison)
must be the next instruction.
Presumably you haven't done this because of the overflow issues.
I'll approve it with one condition -- a testcase which exhibits the bug :-)
I don't doubt the existance of the bug, but I want to be able to point to
something in the testsuite if someone later asks about a performance regression
related to this problem.
Presumably hacking up loop-2f ought to give you a suitable test. Or include
it as another test in loop-2f itself.