public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Richard Biener <richard.guenther@gmail.com>
To: Steven Bosscher <stevenb.gcc@gmail.com>
Cc: GCC Patches <gcc-patches@gcc.gnu.org>,
	Michael Matz <matz@suse.de>, Jeff Law <law@redhat.com>
Subject: Re: [patch][RFC] bitmaps as lists *or* trees
Date: Tue, 05 Mar 2013 12:32:00 -0000	[thread overview]
Message-ID: <CAFiYyc0tkw3kji84zACHUZ57Z_+acm8vnKpOHwo1EKpQijPCAQ@mail.gmail.com> (raw)
In-Reply-To: <CABu31nNJFymyJRTia6ybuugS8gEgVH1hDGpXiXGtJmnbK4T-sA@mail.gmail.com>

On Tue, Mar 5, 2013 at 1:00 PM, Steven Bosscher <stevenb.gcc@gmail.com> wrote:
> Hello,
>
> A recurring problem with GCC's sparse bitmap data structure is that it
> performs poorly for random access patterns. Such patterns result in
> linked-list walks, and can trigger behavior quadratic in the number of
> linked-list member elements in the set.
>
> The attached patch is a first stab at an idea I've had for a while:
> Implement a "change of view" for bitmaps, such that a bitmap can be
> either a linked list, or a binary tree. I've implemented this idea
> with top-down splay trees because splay tree nodes do not need
> meta-data on (unlike e.g. color for RB-trees, rank for AVL trees,
> etc.) and top-down splay tree operations are very simple to implement
> (less than 200 lines of code). As far as I'm aware, this is the first
> attempt at allowing different views on bitmaps. The idea came from
> Andrew Macleod's tree-ssa-live implementation.
>
> The idea is to convert the bitmap to a tree view if the set
> represented by the bitmap is mostly used for membership testing, and
> not for iterations over the items (as e.g. for bitmap dataflow). A
> typical example of this is e.g. invalid_mode_changes, which just
> explodes for the test case of PR55135 at -O0.
>
> I haven't tested this patch at all, except making sure that it
> compiles. Just posting this for discussion, and for feedback on the
> idea. I know there have been many others before me who've tried
> different data structures for bitmaps, perhaps someone has already
> tried this before.

Definitely a nice idea.  Iteration should be easy to implement (without
actually splaying for each visited bit), the bit operations can use the
iteration as building block as well then.

Now, an instrumented bitmap to identify bitmaps that would benefit
from the tree view would be nice ;)  [points-to sets are never modified
after being computed, but they are both random-tested and intersected]

What I missed often as well is a reference counted shared bitmap
implementation (we have various special case implementations).
I wonder if that could even use shared sub-trees/lists of bitmap_elts.

Richard.

> Ciao!
> Steven

  reply	other threads:[~2013-03-05 12:32 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-03-05 12:01 Steven Bosscher
2013-03-05 12:32 ` Richard Biener [this message]
2013-03-05 14:48   ` Michael Matz
2013-03-05 16:17     ` Steven Bosscher
2013-03-05 22:56       ` Steven Bosscher
2013-03-07 20:18         ` Steven Bosscher
2018-10-17 14:04           ` Richard Biener
2013-03-06 10:18       ` Richard Biener
2013-03-06 16:02       ` Jan Hubicka
2013-03-06 16:06         ` Jan Hubicka
2013-03-06 18:07           ` Steven Bosscher
2013-03-06 17:59         ` Steven Bosscher
2013-03-06 18:03           ` Jan Hubicka
2013-03-05 14:51   ` Steven Bosscher
2013-03-05 16:03     ` Richard Biener

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAFiYyc0tkw3kji84zACHUZ57Z_+acm8vnKpOHwo1EKpQijPCAQ@mail.gmail.com \
    --to=richard.guenther@gmail.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=law@redhat.com \
    --cc=matz@suse.de \
    --cc=stevenb.gcc@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).