Thanks Tamar,
as a note: I just pushed the changes that removes GCC's compile time
warnings (as in building these transformations will output less
warnings.) Fuzzying the code found no random programs out of 50,000 that
triggered errors with field reordering and dead field elimination (i.e.
-O2 -flto -flto-partition=none -fipa-field-reorder
-fipa-type-escape-analysis). I understand the limitations of fuzzying,
but I hope that this can provide a base level of confidence. I will be
fuzzying again during the weekend with -Ofast.
Let me know if there's anything else I can do.
On 20/08/2020 21:41, Tamar Christina wrote:
Hi Erick,
Thanks for updating the branch! From some initial testing it seems to result in
some nice gains for mcf but also in lower peak memory usage and smaller
binaries even for benchmarks that don't show an improvement in runtime though I
haven't looked at these more closely yet.
I think you did a decent amount of cleanup during this update (some outstanding
but it hopefully won't block getting some feedback on the approach).
For those who missed it Erick addressed some of the feedback in his previous
message https://gcc.gnu.org/pipermail/gcc/2020-August/233354.html
Jakub and Richi I know you two had the strongest objections, Jakub If I am to
understand yours correctly it's that you don't think type based escape analysis
would be useful in real world code?
While I would agree that it's fundamentally more restrictive than an object
based one I wouldn't say it's useless. At the very least it gives us something
to build on later.
Richi I believe the style issues and the code not being very GCC like prevented
you from having a closer look. That was very helpful feedback and some of it
has been addressed and hopefully enough for you to take a second look?
I know both of you are busy but we really appreciate the feedback so far. Our
goal is to work with the GCC community to come to an acceptable solution for
all parties.
I know the patch looks big, but most of it are machinery and tests.
If there is anything we can do to make this easier for you to review do let us
know.
Thanks,
Tamar
-----Original Message-----
From: Erick Ochoa <erick.oc...@theobroma-systems.com>
Sent: Monday, August 17, 2020 2:53 PM
To: GCC Development <gcc@gcc.gnu.org>
Cc: Christoph Müllner <christoph.muell...@theobroma-systems.com>;
philipp.toms...@theobroma-systems.com; Tamar Christina
<tamar.christ...@arm.com>; Kevin Smith
<kevin.sm...@amperecomputing.com>; Gary Oblock
<g...@amperecomputing.com>; Richard Biener
<richard.guent...@gmail.com>; Martin Jambor <mjam...@suse.cz>; Jan
Hubicka <hubi...@ucw.cz>; Ashok Bhat <ashok.b...@arm.com>;
mli...@suse.cz; Kyrylo Tkachov <kyrylo.tkac...@arm.com>
Subject: [RFC] LTO Dead Field Elimination and LTO Field Reordering
Hello again,
I have committed a couple of changes to the branch
refs/vendors/ARM/heads/arm-struct-reorg-wip
where my transformations are currently residing. This week I'll be working on
fixing several warnings and fuzzying these passes.
2020-08-17 Erick Ochoa
* Can be bootstrapped
* Fixes bug that prevented CPU 2017 gcc benchmark from compiling
2020-08-11 Erick Ochoa
* Initial contribution of field reordering and dead field elimination.
Thanks again for your time. If you have any question or comments, let me
know.
