This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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?

Andrew Pinski

On Tuesday, May 20, 2003, at 15:48 US/Eastern, wrote:

In message <>, Jason Merrill writes:
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. It's
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 IF_STMTs
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
  -O2                     50800
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 COND_EXPRs.
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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]