In message <20030130175337.GA13405@tornado.toronto.redhat.com>, Diego
Novillo w
rites:
On Thu, 30 Jan 2003, Jeff Law wrote:
Q. were you finding that the sequences of labels were typically
normal
labels or case statement labels? Just curious...
Case labels are the overwhelming majority. The worst case is
insn-extract.c and insn-attrtab.c with 696 and 654 case labels
coalesced respectively (not surprising).
OK. That's basically what I expected.
We almost never find normal labels. genrecog.c has 2 and
insn-recog.c has 5.
OK.
I found these numbers using the attached patch for
-fdump-tree-cfg-stats.
Great.
FYI, the coalescing patch is causing a testsuite regression
Running
/portal/fall/virgin-tree-ssa/gcc/testsuite/gcc.misc-tests/bprob.exp > ...
FAIL: gcc.misc-tests/bprob-1.c execution, -O3 -DPERFTIME
-fprofile-arcs
FAIL: gcc.misc-tests/bprob-1.c execution, -O3 -g -DPERFTIME
-fprofile-arcs
Both of these pass if I back out the coalescing patch.
Interestingly enough
most of the absolute time savings came from GCSE. Before the
patch, GCSE would take 36 secs, after the patch it takes 24 secs.
It also improved scheduling2 by 6 seconds. I wasn't expecting
this.
Definitely a surprise. It seems to me that the RTL code would have
coalesced those empty blocks, so it's a real surprise that this sped
up gcse. Any thoughts on how/why?
Nope. I can't see why this could happen. Oh well, more food for
thought.
Definitely. Very weird.
Err, if coalescing labels changes the number of edges so that when we
do it at the tree level, we end up with a lot less edges than we do it
at the RTL level, this would easily explain the GCSE speed difference,
since the lcm is edge based, and the iteration order isn't optimized at
all.