This is the mail archive of the
mailing list for the GCC project.
Re: update_stmt calls
- From: Daniel Berlin <dberlin at dberlin dot org>
- To: Zdenek Dvorak <rakdver at atrey dot karlin dot mff dot cuni dot cz>
- Cc: gcc at gcc dot gnu dot org, amacleod at redhat dot com, dnovillo at redhat dot com
- Date: Tue, 28 Feb 2006 23:50:26 -0500
- Subject: Re: update_stmt calls
- References: <20060301043123.GA12384@atrey.karlin.mff.cuni.cz>
On Wed, 2006-03-01 at 05:31 +0100, Zdenek Dvorak wrote:
> during a recent discussion, it was pointed to my attention that
> update_stmt is performance critical. I wondered why; this is the number
> of update_stmt calls for combine.i (all the other passes have less then
> 1000 calls):
> tree VRP : 17543 (10%)
> tree copy propagation : 3210 ( 2%)
> tree alias analysis : 113845 (67%)
> tree SSA other : 20824 (12%)
> dominator optimization: 1411 ( 1%)
> tree split crit edges : 3122 ( 2%)
> tree FRE : 2060 ( 1%)
> expand : 5703 ( 3%)
> TOTAL : 170549
> I have a patch that decreases number of update_stmt calls in tree alias
> analysis to 46525;
By doing what?
I'm about to be forced to add a few more cases of TODO_update_tmt_usage.
> still, is it really that useful to run pass_may_alias
> *six* times during compilation?
The one after PRE will be removed when i get a few days.
> Obviously, we need the initial one, and
> there are comments after pass_sra and pass_fold_builtins that indicate
> that the following pass_may_alias cannot be avoided (which seems
> doubtful to me, at the very least in the later case),
You are always welcome to try.
> but the remaining
> three seem to be just placed randomly.
The first one is placed after some initial cleanups have taken place
that may have given us the ability to generate better aliasing
information (due to removed blocks, conditionals, etc).
The one after PRE is because PRE inserts new pointers and dereferences
but doesn't copy the name and type tags from the original vars.
I imagine the one after DSE is to work around some bug, it certainly
doesn't improve precision in any way.
> I also have a patch that decreases the number of update_stmt calls
> in VRP to 5229 (which is more or less the number of ASSERT_EXPRs it
> creates, so this cannot be improved significantly).