> I think something like
>
> struct gimple_statment_base
> {
> enum gimple_stmt_code code : 8;
> unsigned int subcode : 24;
> source_locus locus;
> tree block;
Just jumping late into the debug info discussion, RTL locators are
combining TREE blocks and source_locuses into single integer. This works
well since they are related (when you want to preserve block you likely
want to preserve line number too and vice versa) and you have one
integer per statement + integer+pointer pair in the on side lookup table
for each of block/line numbers, so I would say it is as effecient as one
would like. Doing the same on GIMPLE level would leave us with
one set of locators to use in backend.
I already played a bit with this idea and saving tree pointer for
different purpose as followup of my patch
http://gcc.gnu.org/ml/gcc-patches/2007-03/msg01169.html It is moderately
ugly because the approach does not work too well for frontends so I
decided to not do it for a moment, but if we separate gimple and
frontend trees, it would be clean solution.
One approach I was considering is also to extend libcpp linemaps to deal
with blocks too (via extension API). We then can keep frontends using their
BLOCK trees but during conversion to gimple we can simply produce new locus
numbers that already combine both info together.
This way we can get around without tree block pointer completely,
assuming that frontends don't need it and we finish linemap conversion.
>
> > * Unfortunately, we're going to have to duplicate a lot of the functionality
> > we currently have for trees. For example, since STATEMENT_LISTs are used
> > before gimplification, we'll have to come up with the equivalent thing
> > for tuples (say, GIMPLE_STATMENT_LISTS).
>
> Sort of. I think you'd want to merge tree_statement_list_node
> into gimple_statement_d, to avoid the extra indirection to get
> to the statement.
I am also happy merging the tree list into statement itself is
considered. From earlier discussions it seemed to me that this idea was
already gave up.
Honza
>
>
> r~
