------- Comment #14 from law at redhat dot com 2006-03-30 17:15 ------- Just a note on the compile-time regressions for tramp3d...
After fixing the timevars it was pretty clear that it isn't the cprop code itself that is slow, it is in fact very fast. THe slowdowns for tramp3d are in operand scanning and incremental SSA updates. I built a little instrumentation code and was rewarded with some insight into why tramp3d behaves differently for operand scanning. When we propagate into a statement, we (of course) fold and rescan the operands for the use statement. Clearly if we propagate several distinct copies into a single use statement, then we end up wasting time rescanning the use statement. My instrumentation recorded how often we perform more than one propagation into a statement vs how often we only propagate into a statement one time. In my test bucket that ratio is a little less than 1:1. I would have expected significantly smaller, but it is what it is. What's interesting is that for tramp3d that ratio is about 3:1 -- primarily from copy propagating into VUSE and V_MAY_DEF operands. I'm currently experimenting with some code to queue folding/rescanning of use statements in cases where there's a reasonable chance we're going to do more than one propagation into the statement. Initial experiments are showing a measurable compile-time improvement for both tramp3d as well as my testbucket. [ Note that Diego's memory tag rewrite work may make all this moot one day... ] Jeff -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21829
