[Bug ipa/92800] New: IPA escape analysis for structs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92800 Bug ID: 92800 Summary: IPA escape analysis for structs Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ipa Assignee: unassigned at gcc dot gnu.org Reporter: christoph.muell...@theobroma-systems.com CC: marxin at gcc dot gnu.org Target Milestone: --- Having GCC infrastructure code to detect non-escaping structs during whole-program analysis opens the door for the field of struct reorganisation optimisations. We are currently working on such infrastructure and want to use this ticket to further publish details and patches, and to collect feedback from the community. First implementation details: * escape analysis for RECORD_TYPE types * supporting code for IPA passes * running after IPA visibility * checking all externally visible symbols/signatures * checking all type casts
[Bug ipa/92801] New: Drop unused struct fields
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92801 Bug ID: 92801 Summary: Drop unused struct fields Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ipa Assignee: unassigned at gcc dot gnu.org Reporter: christoph.muell...@theobroma-systems.com CC: marxin at gcc dot gnu.org Target Milestone: --- Non-escaping structs [1] can have their unused fields removed such that they have a smaller memory footprint and thus allow a more efficient cache utilisation. We are currently working on such a pass and want to use this ticket to further publish details and patches, and to collect feedback from the community. First implementation details: * Iterate with gsi over function bodies to find field accesses (e.g. in assignment, call, cond or switch statements). * Allowed for removal if never accessed * Allowed for removal if write-only (incl. removal of write statements) * Removal based on modification of DECL_CHAIN() of TYPE_FIELDS(t) Early tests showed, that this has the potential to eliminate struct fields nextout and nextin from struct arc of CPU2017's mcf benchmark. As elements of an struct arc array are accessed for the main calculation in the hot loop, this benchmark is a good example, where this pass will help. [1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92800
[Bug ipa/92538] Proposal for IPA init() constant propagation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92538 --- Comment #4 from Christoph Müllner --- Early tests with this pass showed that a bunch of SPEC CPU2017 benchmarks benefit from this. For example, the written-once global variable TTSize of sjeng is eliminated by this pass.
[Bug ipa/92802] New: Struct field reordering
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92802 Bug ID: 92802 Summary: Struct field reordering Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ipa Assignee: unassigned at gcc dot gnu.org Reporter: christoph.muell...@theobroma-systems.com CC: marxin at gcc dot gnu.org Target Milestone: --- Non-escaping structs [1] can be rearranged such that they have a smaller memory footprint and thus allow a more efficient cache utilisation. We are currently working on such a pass and want to use this ticket to further publish details and patches, and to collect feedback from the community. First implementation details: * Reordering is based on modification of DECL_CHAIN()s of TYPE_FIELDS(t) * Reordering based on size (biggest to smallest) [1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92800
[Bug ipa/92801] Drop unused struct fields
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92801 --- Comment #2 from Christoph Müllner --- Yes, our current approach is all or nothing (i.e. all uses of a struct are changed or none). Optimizing individual uses of a type would allow a more tailored optimization. We decided to defer such an approach in our first shot because it would make the analysis more complex as we would make individual struct uses incompatible and we would have to track these uses of the structs (across compilation units).
[Bug ipa/92800] IPA escape analysis for structs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92800 --- Comment #2 from Christoph Müllner --- Thanks for mentioning that. We have an upcoming conf call with Marvell where we will discuss this.