------- Additional Comments From law at redhat dot com 2004-11-01 21:18 ------- Subject: Re: [4.0 Regression] jump threading on trees is slow with switch statements with large # of cases
On Mon, 2004-11-01 at 16:56 +0000, giovannibajo at libero dot it wrote: > ------- Additional Comments From giovannibajo at libero dot it 2004-11-01 16:55 > ------- > > The effect for the test case of this PR is huge. > > The effect on everything else (for example insn-attrtab) is not > > measurable. > > We have had many bug reports from users trying to compile interpret-like code > which is machine generated and is effectively made by giant switch statements. > Improving this PR will definitely make their code go faster. > > In fact, if we are going to have a performance testsuite for GCC (as I asked to > the SC lately), I would surely propose to put such a testcase in there. But how often are those codes going to trigger jump threading and edge splitting. Just having large switches isn't enough to cause us to trip over the representational issues that are giving us so many compile-time problems. jeff ------- Additional Comments From law at redhat dot com 2004-11-01 21:18 ------- Subject: Re: [4.0 Regression] jump threading on trees is slow with switch statements with large # of cases On Mon, 2004-11-01 at 20:17 +0000, stevenb at suse dot de wrote: > ------- Additional Comments From stevenb at suse dot de 2004-11-01 20:17 ------- > Subject: Re: [4.0 Regression] jump threading on trees is slow with switch > statements with large # of cases > > > I think it'll ultimately be cleaner to simply drop the labels after > > we've built the CFG and associate an edge with each of the cases. > > Yes, this is what I would really want to do, but I don't know if such > a patch would be safe for GCC 4.0. I think this can be done in a reasonably localized way. We convert to using edges just after building the CFG and we return to using labels after we're done with the SSA path. I don't expect we'll have much (if any) code that has to handle both representations. > I suppose we could introduce a fake > 'x' class tree with is really just a VEC(edge) plus a tree_common, and > stuff that into SWITCH_LABELS (which would at that point not longer be > an appropriate name of course ;-). Or break out case labels in a manner similar to what we do with other nodes that have "interesting" fields. > The trouble is that we still need > to recreate the labels for expand, that's the ugly part. Na. That's trivial. jeff -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15524