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
