On Wed, 2006-03-01 at 05:31 +0100, Zdenek Dvorak wrote: > Hello, > > 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). > > Zdenek >
