This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Extreme PRE compile times
- From: law at redhat dot com
- To: Daniel Berlin <dberlin at dberlin dot org>
- Cc: gcc at gcc dot gnu dot org
- Date: Thu, 13 Nov 2003 09:47:29 -0700
- Subject: Re: Extreme PRE compile times
- Reply-to: law at redhat dot com
In message <Pine.LNX.4.56.0311131122300.29117@dberlin.org>, Daniel Berlin write
s:
>> >
>> > Clearly PRE is still doing something that's not terribly intelligent give
>n
>> > that PRE + the increase the GC time accounts for 90% of the total
>> > compilation time for this file.
>
>Looking at the dumps, it looks (it's not finished yet) like all the
>replacements it's performing are ones that could have been caught
>by the dominator optimizers:
>
>In BB 1, insert save of this.2_4528 + 2B to pretmp.12002_44554 before
>statement T.4_4566 = pretmp.12002_44554
> on line 417
>In BB 15988, insert reload of this.2_4528 + 2B from pretmp.12002_44554 in
>statement T.4_44534 = this.2_4528 + 2B;
>
> on line 417
>
>
>
>In BB 3, insert save of this.2_4528 + 4B to pretmp.12004_44563 before
>statement T.6_4572 = pretmp.12004_44563
> on line 417
>In BB 15982, insert reload of this.2_4528 + 4B from pretmp.12004_44563 in
>statement T.6_44520 = this.2_4528 + 4B;
>
>
>
>None of these expressions are causing new phis to be inserted, which means
>they aren't partially redundant.
Which probably argues that you should have some kind of filter which
eliminates certain expressions from your candidates for PRE. Trying to
PRE something which isn't partially redundant is kindof silly.
Similar filtering on variables before PHI insertion on this testcase was
a huge win.
Also, as I've stated before, if we're leaving in redundancies like this after
DOM, I'm more than happy to look at it if you can give me a reasonable
testcase.
jeff