Re: if-conversion a performance bottleneck

[Jeffrey A Law <law at cygnus dot com>]

  In message <Pine.SOL.4.10.10005030741450.1121-200000@platon>you write:
  >   This message is in MIME format.  The first part should be readable text,
  >   while the remaining parts are likely unreadable without MIME-aware tools.
  >   Send mail to mime@docserver.cac.washington.edu for more info.
  > 
  > ---559023410-33463914-957333180=:1121
  > Content-Type: TEXT/PLAIN; charset=US-ASCII
  > 
  > Hi,
  > 
  > On Tue, 2 May 2000, Michael Matz wrote:
  > > >  time   seconds   seconds    calls  ms/call  ms/call  name    
  > > >  57.51 111.67 111.67 40604 2.75 2.75 sbitmap_intersection_of_succs
  > > >  12.83 136.59 24.92  15025 1.66 1.66 sbitmap_intersection_of_preds
  > > 
  > > I once had faster versions of these two functions, if I get home I'll see
  > > if they make any difference on your input data.
  > 
  > Before fiddling with sbitmap_intersection_of_xx() I first reworked
  > compute_flow_dominators() to also behave normally in calculating the
  > post_doms. At least the order of work-queue initialization was wrong (in
  > post_dom the changes are propagating from the _end_). I then also
  > implemented a poor man's topological sort for cyclic graphs ;), which
  > again gave a better performance. (I also did this once for doms, but there
  > it didn't make a great difference on Brads test cases)
  > 
  > Please try the attached diff (against actual CVS) if they make also a
  > difference for you ;)
Like Richard, I'd like to see you submit this as a function which can be
called from multiple locations in the compiler.

We've got a number of routines that _might_ benefit from this code, but
I'd also like to see some more general benchmarking.  I don't want to
see us slow down the compiler for the common cases just to make Brad's
one test run faster.

jeff