LTO Dead Field Elimination

[David Brown]

On 24/07/2020 17:43, Erick Ochoa wrote:
> This patchset brings back struct reorg to GCC.
> 
> We’ve been working on improving cache utilization recently and would
> like to share our current implementation to receive some feedback on it.
> 
> Essentially, we’ve implemented the following components:
> 
>     Type-based escape analysis to determine if we can reorganize a type
> at link-time
> 
>     Dead-field elimination to remove unused fields of a struct at link-time
> 
> The type-based escape analysis provides a list of types, that are not
> visible outside of the current linking unit (e.g. parameter types of
> external functions).
> 
> The dead-field elimination pass analyses non-escaping structs for fields
> that are not used in the linking unit and thus can be removed. The
> resulting struct has a smaller memory footprint, which allows for a
> higher cache utilization.
> 

I am very much a lurker on this list, and not a gcc developer - I am
just an enthusiastic user.  So my opinion here might not even be worth
the apocryphal two cents, and I won't feel insulted if someone says I
don't know what I am talking about here.

With that disclaimer out of the way, my immediate reaction to this idea
is "Why?".

What is the aim of this feature?  I can see it making many things a lot
more complicated, but I can't see it being of correspondingly
significant benefit.

Do you have reason to suppose that there really are many structs in use
in real code, for which there are fields that aren't used, and for which
removing those fields makes a /significant/ improvement to the
efficiency of the code?

If I have the history correct, gcc used to have an optimisation that
would let it re-order fields in a struct to reduce padding.  This got
removed in later versions because it made things so complicated in other
parts of compilation and linking, especially if some parts of the code
are compiled with different options.  Why would these new features not
suffer from exactly the same kinds of issues?

I worry that this kind of global optimisation has so many knock-on
effects that it simply is not worth the cost.  Remember that it is not
just in writing these patches that work must be done - people are going
to have to maintain the code for ever after, and it could mean changes
or limitations in other parts of gcc.

As I see it, there is a simpler path with much lower cost.  When I am
writing code, if I have poor struct layout or unnecessary fields, I
don't want the compiler to re-organise things behind my back.  I want to
be /told/.  Either I want the field there (perhaps I haven't written the
code that uses it yet), or I've made a mistake in my code.

My recommendation here would be to keep the analysis part - that could
be useful for other features too.  But drop the optimisation part -
replace it with a warning.  Tell the programmer, and let /them/ decide
whether or not the field is unnecessary.  Let the programmer make the
decision and the change - then you get all the benefits of the
optimisation with none of the risks or complications.

David