This is the mail archive of the gcc-patches@gcc.gnu.org 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: [Bug middle-end/15855] [3.4/4.0 Regression] g++ crash with -O2and -O3 on input file


This gives us a small (.5%), but measurable speedup for 15855.

Given two sbitmaps, there's a few places where we just want to know if
there are bits in common.  We don't care about precisely what those
bits are -- just whether or not there are some in common.

Right now we use sbitmap_a_and_b, then scan the result to see if any
bits are set.  That is clearly inefficient; let me count the ways...

  1. We have to have an sbitmap for the destination.  That means
     allocation and teardown of an extra sbitmap.

  2. For every bit X that is set in A & B we have to set the
     appropriate bit in the destination sbitmap.

  3. We do not need to scan any bits beyond the first which is
     common in A & B.   Nor do we really need to set any of those
     bits in the destination.

  4. After the sbitmap_a_and_b call is completely we have to scan
     the destination bitmap to see if any bits are set.

Ugh.

This patch introduces a new sbitmap function which just returns 
a boolean indicating whether or not the two given bitmaps have
any common bits set.  It does not tell us what bits were common,
how many, or anything like that.

Less work, less memory allocated, faster compilation times.  Mmm, good.


Bootstrapped and regression tested on i686-pc-linux-gnu.


Attachment: PPP
Description: Text document


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