Less draconian decision in gcse.c?

[Brad Lucier <lucier at math dot purdue dot edu>]

In gcse.c one finds the code:

  /* Trying to perform global optimizations on flow graphs which have
     a high connectivity will take a long time and is unlikely to be
     particularly useful.

     In normal circumstances a cfg should have about twice has many edges
     as blocks.  But we do not want to punish small functions which have
     a couple switch statements.  So we require a relatively large number
     of basic blocks and the ratio of edges to blocks to be high.  */
  if (n_basic_blocks > 1000 && n_edges / n_basic_blocks >= 20)
    return 0;

As many of you know ;-), a lot of the code I compile with gcc is
organized as a state machine.  Function calls are gotos, returns are
computed gotos, locations of returns are noted by storing the address
of the return label in a variable.

In general, gcse would benefit these codes, except for the function
returns.  The test in gcse.c is too draconian.

How difficult would it be to do gcse analysis across all edges except
those edges out of a computed goto?  Can one set up the usual analysis with
a restricted flow graph that does not include these edges, but does contain
all other edges?

Brad Lucier