This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: update_stmt calls

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):


I have a patch that decreases number of update_stmt calls in tree alias
analysis to 46525; still, is it really that useful to run pass_may_alias
*six* times during compilation?  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), but the remaining
three seem to be just placed randomly.

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).

I can't say I'm suprised, there was a time when the general rule was "when in doubt, update", so not a lot of thought has gone into those calls, especially in the older passes. Anything which reduces the calls to update_stmt() is a probably good thing :-)

I can't speak to the number of calls to pass_may_alias, but that does seem a bit excessive to me as well. To the best of my knowledge, no one has recently (if ever) sat down and figured out which passes we actually need where and when. They just get added when people think they are a good idea, but rarely get removed later when things change. I would suspect there are numerous passes that could be eliminated with some analysis and shuffling. Thats something that would be easier to do with a dynamic pass manager :-)


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]