------- Additional Comments From law at redhat dot com 2005-04-22 18:30 ------- The reload bug has been "resolved" or at least it's in a state where we can move forward with the jump threading changes.
I've finally got the dynamic branching data which shows pretty much what I expected -- we execute fewer jumps :-) What I've done is used GCC's arc-profiling and branch prediction support to give us a picture of the runtime branching behavior of a set of programs (SPECINT2000). Specifically we're looking at how many conditional branches were executed (regardless of whether or not they were taken or not taken). We measure this with and without the jump threading changes. This gives us a highly accurate measure of how effective the jump threading changes are at reduncing the number of branches a program executes at runtime (it does not measure the secondary effects like exposing new expression redundancies). For SPECINT2000 we see a reduction in conditional branches of 4%. Yes, the threading changes manage to eliminate 4 out of every 100 branches executed at runtime across a fairly large benchmark suite. One benchmark (gzip) saw an incredible 21% reduction in runtime branches executed, though sadly gzip doesn't show a measurable runtime improvement (most likely because there were few, if any secondary optimization opportunities exposed by jump threading and/or the branches it eliminated were easily predicted by the hardware and thus weren't causing considerable branch mis-prediction penalties). These changes are also now showing a net improvement in compile-time. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19794
