This is the mail archive of the
mailing list for the GCC project.
Re: [PATCH] [RFC] loop index promotion pass
- From: Richard Guenther <richard dot guenther at gmail dot com>
- To: Mark Mitchell <mark at codesourcery dot com>
- Cc: gcc-patches at gcc dot gnu dot org
- Date: Wed, 20 May 2009 10:51:05 +0200
- Subject: Re: [PATCH] [RFC] loop index promotion pass
- References: <20090423161719.GV22588@codesourcery.com> <email@example.com> <20090424184303.GZ22588@codesourcery.com> <firstname.lastname@example.org> <4A133750.email@example.com>
On Wed, May 20, 2009 at 12:48 AM, Mark Mitchell <firstname.lastname@example.org> wrote:
> Richard Guenther wrote:
>>>>> Bootstrapped on x86_64-unknown-linux-gnu. ?Comments welcome.
>> Ok, I did that. ?It regularizes the code, but with no effect on the generated
>> code. ?It seems that SCEV analysis is confused enough to not be able to
>> compute the scalar evolution for the loads at all (I didn't yet "fix" the
>> SCEV code wrt no-undefined-overflow semantics though).
> Nathan's new pass has significant impact on benchmarks that people
> routinely use to judge GCC. ?These benchmarks are based on real-world
> code; a lot of code for 8- and 16-bit machines used "short" in lots of
> places because that was faster, and that code is now running on 32-bit
> machines. ?So, I don't think the pass is purely a benchmark hack -- but
> even if it was, I think that GCC having good benchmark numbers is a good
> thing, if that doesn't interfere with its other goals.
> I think we should accept the patch (modulo, of course, any fixes
> required in the ordinary course of review), unless someone sees a
> better, and relatively easy, way to provide the same benefit. ?We can
> always rip it out if there turns out to be a better way.
> (For avoidance of doubt, CodeSourcery has no commercial reason to care
> whether -fpromote-loop-indices makes it into the FSF tree or not.)
I'd like to see compile-time numbers. And I am not convinced
(after looking at the testcase) that this transformation is valid
unless you can prove that the narrower IVs do not wrap.
Nathan, can you convince me that you are properly checking
if the transformation is valid?
(oh, and of course the patch itself is still unreviewed)