This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [tree-ssa] Coalescing label blocks [patch]
- From: law at redhat dot com
- To: Diego Novillo <dnovillo at redhat dot com>
- Cc: gcc-patches at gcc dot gnu dot org
- Date: Thu, 30 Jan 2003 11:34:55 -0700
- Subject: Re: [tree-ssa] Coalescing label blocks [patch]
- Reply-to: law at redhat dot com
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.
jeff