On Mon, Nov 04, 2024 at 10:58:14AM +0100, Richard Biener wrote:
> > Regarding memory usage implications of this change. It does make a lot of
> > data structures larger. Here is what it does on x86-64. The base sizes of 
> > some
> > types change as follows:
> >
> > location_t:              From 4 to 8 (+100%)
> > line_map_ordinary:       From 24 to 32 (+33%)
> > line_map_macro:          From 32 to 40 (+25%)
> > cpp_token:               From 24 to 32 (+33%)
> > cpp_macro:               From 48 to 56 (+17%)
> > tree_exp:                From 32 to 40 (+25%)
> > gimple:                  From 40 to 48 (+20%)
> 
> All GENERIC decls (tree_decl_minimal) will grow by 8 bytes (and we have 4 
> bytes
> unused padding).  On the GIMPLE side it's probably a "hooray - more space for
> flags!".  It does feel a bit backwards because the savings we got by making
> the TREE_BLOCK part of the location.

I think we need to carefully look at each of the structs with location_t
that is used widely.
E.g. for tree_exp, I think we just had a padding there up to and including
GCC 13, and in GCC 14+, while EXPR_COND_UID is computed unconditionally, it
is ignored unless -fcondition-coverage which is not enabled by default and
I think it isn't commonly used and is used solely on COND_EXPRs.
Furthermore, for gimple we don't waste precious space for it and use on the
side hash map, so why not use similar hash-map for COND_EXPRs during
gimplification too (and only for -fcondition-coverage)?
That would keep tree_exp at the same size as before.

Other than that, guess gimple is the most important, especially for LTO.
Except for GIMPLE_CALL/ASM/SWITCH, most GIMPLE_* codes have very low num_ops,
so perhaps having 32-bit num_ops is a waste.
Though we'd need 3 bits to represent those, or at least 2 if GIMPLE_COND
has it somewhere else.

cpp_token hurts too, at least for C++, though I'm not sure what to do that.
While most of the union members are just 32 or 64-bit, there are two with
32-bit and 64-bit data (that could be in theory handled by having the 32-bit
stuff in some flags field and union just the 64-bit) but then for identifiers
we want 2 pointers.

        Jakub

Reply via email to