This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: [new-regalloc] What is the status on current sources
- To: Zack Weinberg <zackw at stanford dot edu>
- Subject: Re: [new-regalloc] What is the status on current sources
- From: Daniel Berlin <dberlin at redhat dot com>
- Date: Sat, 10 Feb 2001 13:26:03 -0500 (EST)
- cc: Daniel Berlin <dberlin at redhat dot com>, Michael Matz <matzmich at cs dot tu-berlin dot de>, Geert Bosch <bosch at gnat dot com>, "gcc at gcc dot gnu dot org" <gcc at gcc dot gnu dot org>
On Fri, 9 Feb 2001, Zack Weinberg wrote:
> On Sat, Feb 10, 2001 at 02:13:40AM -0500, Daniel Berlin wrote:
> >
> > It's one of those "in theory, worst case, it's O(n), and slow. In
> > practice, it's lightning fast, on anything we use it for, because we
> > generate cases close to optimal"
>
> This will make three different bitmap systems in gcc (sbitmap, bitmap,
> and yours). They all have the same basic interface, but different
> back-end representations. Do you think it would be feasible to merge
> them all into some sort of parametrized thingy?
Sure.
It might actually pay, however, to make the parameterization be based on
"speed" or "space", or something, so that we could build a bitmap that
automatically switched representations when it got too large, or
something.
This is, of course, a bit more difficult than just merging all three into
one set of bitmap functions, but might be more useful.
Maybe I should just move this stuff into libiberty anyway?
> > zw
>