This is the mail archive of the
mailing list for the GCC project.
Re: [ tree-ssa] Eliminate more GOTO_EXPRs
- From: Andrew Pinski <pinskia at physics dot uc dot edu>
- To: law at redhat dot com
- Cc: Andrew Pinski <pinskia at physics dot uc dot edu>, Jason Merrill <jason at redhat dot com>, gcc-patches at gcc dot gnu dot org
- Date: Tue, 20 May 2003 15:54:34 -0400
- Subject: Re: [ tree-ssa] Eliminate more GOTO_EXPRs
What about looking at insn-recog.c, which has loads of goto's in it,
does the tree-ssa branch do better job than the mainline with the hack?
On Tuesday, May 20, 2003, at 15:48 US/Eastern, email@example.com wrote:
In message <firstname.lastname@example.org>, Jason Merrill
Good timing; I'm about to check in a patch that generates useless
GOTO_EXPRs like that. :)
Note there's still tons of unnecessary gotos in the code we generate.
an artifact of the gimplification process.
When we gimplify trees, we transform IF_STMTs into COND_EXPRs.
c-semantics and friends are reasonably intelligent about expansion of
to avoid creating unnecessary RTL, particularly for empty ELSE clauses.
expr's handling of COND_EXPRs is a lot less intelligent and as a result
generates labels & jumps for those empty else clauses.
To give you a sense of scale here's some simple insn counts in the .rtl
dump when compiling combine.i
-O2 -fdisable-simple 35607
Ouch. We're generating 15000 more insns when we gimplify and tree-ssa
optimize combine.i. That's a 42% higher insn load.
-O2 with COND_EXPR hack 43195
This hack just makes expr.c a little smarter about expanding
As you can see this eliminates 7k unnecessary insns -- or nearly half
of the extra insns generated when we gimplify functions. Yes it's
true all of those useless insns would have been eliminated by the
jump optimizer, but it seems rather silly to generate them in the
first place. I haven't tested the correctness of this code, so you
might want to take this with a grain of salt.