Aldy Hernandez <[EMAIL PROTECTED]> 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
