GC overhead just because of aligning long double?

[Richard Guenther]

On Sun, 18 Oct 2009, Richard Guenther wrote:

> 
> We're waisting 8 bytes for every gimple_seq_node_d on x86_64 just
> because we might be allocating a structure with a long double
> element (16 byte aligned).  I grepped and didn't find traces of
> such a use, so - can we just document that callers need to
> round up allocation sizes to multiples of the required alignment
> (and just enforce that for alignment requirements bigger than pointers)?
> 
> A gimple_seq_node_d should be allocated from 24 byte page sizes
> but are allocated from 32 byte page sizes because of the above
> issue - wasting 25%.

Changing MAX_ALIGNMENT from 16 to 8 on x86_64 makes us go from

Total                                            2788975191        
775857920         40632633        400225192         55862833
source location                                     Garbage            
Freed             Leak         Overhead            Times

to

Total                                            2262618351        
747470600         38848265        122407808         55849810
source location                                     Garbage            
Freed             Leak         Overhead            Times

for SPEC 2006 tonto.  I added gimple_seq_node_d, 40, 56, 72, 88, 104
and 120 as extra sizes of which

Total Allocated page size      24:      589531776
Total Allocated page size      56:      213088232
Total Allocated page size      72:      232481808

have a relevant amount of allocation.

In the past the issue was that gc allocs are not type-safe, so
we sometimes allocate sizes that are not multiples of the required
alignment, like for struct { int len; char c[1]; }.  None
of the existing uses should require larger than pointer alignment
though, so documenting that should be enough.

Richard.