Hello again,
Thanks for replying to my previous thread. I am thankful for all input
received and addressed the comments which I could address. I have been
working on the past two weeks on fixing the style and adding comments
explaining classes and families of functions. I have also added a
prototype for field reordering which takes advantage of the
infrastructure developed during dead field elimination.
I'll explain again what I've been working on and add some technical
notes which might be of interest as well for the sake of keeping the
discussion to a single post in the mailing list.
This patchset adds LTO Dead Field Elimination and Field Reordering as
two different passes. I've been testing LTO Dead Field Elimination for
some time, compiling all C benchmarks in the SPEC CPU 2017 benchmarking
suite. I have not yet tested LTO Field Reordering as extensively but I
can say that it compiles all C benchmarks in SPEC CPU 2017 with the
exception of gcc. Please note that when combining both transformations,
all C benchmarks compile and verify. Please note that the code is made
to crash whenever unexpected tree codes are encountered (such as some
found in C++ and possibly fortran and ada).
One thing that might stand out in this code's review: I implemented my
own tree walking mechanism instead of using walk_tree. The reason for
this is because walk_tree does not provide a way to set a post-order
callback. walk_tree only provides a way to set a pre-order call back.
Doing everything in a pre-order traversal would have required
complicated keeping track of ancestors and jumping back and forth
between ancestors and descendant nodes.
Field reordering brings back the intention of -fpack-struct but without
violating natural alignment. The field reordering transformation allows
to reduce the memory footprint of structs,
which not only improves performance, but also memory consumption.
So this is an interesting feature on embedded systems with tight memory
constraints.
Having said that, I welcome all criticisms and will try to address those
criticisms which I can.
The code is in:
refs/vendors/ARM/heads/arm-struct-reorg-wip
Few notes:
* It is not a "true" ipa pass yes. That is, we can only succeed with
-flto-partition=none.
* Currently it is not safe to use -fipa-sra.
* Brace constructors not supported now. We handle this gracefully.
* Only C as of now.
* Tests will fail unless finding instructions where addresses of fields
is commented out. (Maybe I should create a flag to help testing?). This
is because I use pointer arithmetic to compute at runtime the size of
the struct that I expect to be transformed. (And sometimes when I don't
expect them to be transformed.)
* Results of sizeof() and offsetof() are generated in the compiler
frontend and thus can’t be changed later at link time. There are a
couple of ideas to resolve this, but that’s currently unimplemented.
* At this point we’d like to thank the again GCC community for their
patient help so far on the mailing list and in other channels. And we
ask for your support in terms of feedback, comments and testing.
