This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: tuples: data structure separation from trees
- From: Ian Lance Taylor <iant at google dot com>
- To: Aldy Hernandez <aldyh at redhat dot com>
- Cc: dnovillo at redhat dot com, rth at redhat dot com, jayrav at hotmail dot com, gcc at gcc dot gnu dot org
- Date: 29 Mar 2007 18:24:56 -0700
- Subject: Re: tuples: data structure separation from trees
- References: <20070329201635.GA13790@redhat.com>
Aldy Hernandez <aldyh@redhat.com> writes:
> After doing the GIMPLE_MODIFY_STMT work, I've come to the conlusion that
> to continue overloading trees will be more work in the long run than doing the
> actual separation between tuples and trees. This business of "this is
> a tree, but not really", includes far too much special casing. It seems it's
> best to bite the bullet now and separate the data structures in one sweep.
Yes.
> * By extension, we will also need:
>
> typedef struct gimple_expression_d { ... } * gimple_expr;
>
> For example, PLUS_EXPR, etc. These will have location, btw.
Why will expressions have location? It seems to me preferable to save
the memory. After a few optimization passes many of the expressions
have no location anyhow.
> Something like:
>
> gimple_stmt
> |
> =
> / \
> / \
> / \
> gimple_expr gimple_expr
> | |
> tree +
> | / \
> decl / \
> / \
> / \
> gimple_expr gimple_expr
> | |
> tree tree
As RTH said, we need to pack operands together as much as possible and
avoid pointers as much as possible.
And as long as you are thinking about this, I think it would be very
desirable to not use pointers at all. That could reduce LTO output
serialization to some memory rearrangement plus an mmap call. LTO
serialization input would be pure mmap. For example, perhaps instead
of pointers, always store an offset into an array, and then garbage
collect array entries.
There are a number of other compilers with successful IR
implementations, and some of them are open source, such as LLVM or
Open64. Since you are essentially proposing a new IR, I would
encourage you to take a little time to see if you can learn anything
from their IR implementations.
Sure, we can't get there immediately. And your suggestion may be a
good incremental step. But I'd like to see a little more about the
final destination.
Thanks for looking at this!
Ian