On Mon, Jul 27, 2020 at 9:03 AM Christoph Müllner <christoph.muell...@theobroma-systems.com> wrote: > > Hi Richard, > > On 7/27/20 2:36 PM, Richard Biener wrote: > > On Fri, Jul 24, 2020 at 5:43 PM Erick Ochoa > > <erick.oc...@theobroma-systems.com> 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. > >> > >> As a side-effect a couple of new infrastructure code has been written > >> (e.g. a type walker, which we were really missing in GCC), which can be > >> of course reused for other passes as well. > >> > >> We’ve prepared a patchset in the following branch: > >> > >> refs/vendors/ARM/heads/arm-struct-reorg-wip > > > > Just had some time to peek into this. Ugh. The code doesn't look like > > GCC code looks :/ It doesn't help to have one set of files per C++ class > > (25!). > > Any suggestions how to best structure these? > Are there some coding guidelines in the GCC project, > which can help us to match the expectation?
Thanks for working on this feature in GCC. The coding standards for the GNU Project and for GCC are: https://www.gnu.org/prep/standards/ https://gcc.gnu.org/codingconventions.html As others have mentioned, the documentation should be in the source code itself. An external design document is nice, but the code should seemlessly integrate with the rest of the GCC source code, not a separate, self-contained set of files bolted onto the side. Thanks, David
