On Mon, Jul 27, 2020 at 02:52:21PM +0200, Erick Ochoa wrote:
> I will work on making this more readable. I understand your comments and you
> are right. I am currently in the process of writing a human-readable PDF
> with an overview of this. There is already a (somewhat hurried) version of
> this PDF in the GCC internals link we shared. This should answer most of the
> high level questions about how the type escape analysis is computed.
> However, yes, there is still work to be done. I will start looking into
> walk_tree and walk_gimple* and see if the gimple_walker I wrote is redundant
> and substitute it.
The overview doesn't belong in some on the side document, but should be in
the source (usually at the start of the source file that contains the pass).
And then each function should be documented.
I'd also like to stress what has been seen several times in the past, but is
being not taken into account. One of the reasons why old ipa struct reorg
has been removed is that it worked on the types granularity, if it is safe
to adjust all references to all objects of a certain type, then do it,
otherwise give up. That is fundamentally wrong, it can't be useful except
by pure luck on some benchmark.
Instead, it should work on the object (or sets of those) granularity.
If the analysis phase determines all accesses to certain object (automatic
or global variable, or e.g. memory allocation) can be adjusted by using a
different type for it (with either fields reordered, or some removed etc.),
then it should be optimized regardless of whether other objects can be
optimized similarly or not. In other cases, it will not be possible to
optimize a single object on its own, e.g. some function is called with
an address of one of 10 objects, so in that case put those 10 objects into a
set and either optimize those together if possible, or punt on those
together. But only very seldom all objects of certain type can be optimized
the same way, and even if they do, perhaps it is better to optimize some of
them even further (e.g. you find none of the objects of type XYZ use field
abc, and decide to adjust the type and remove the field. But perhaps 50% of
objects of that type also don't use def field and if those were optimized
separately, you could optimize that too).
Jakub
