On Fri, May 29, 2020 at 8:44 PM Erick Ochoa <erick.oc...@theobroma-systems.com> wrote: > > Hello everyone, > > I wanted to highlight this ticket on bugzilla [0]. It is a missed > optimization that I worked on. It involves propagating constants across > function calls at link-time. I am relatively new to GCC and this would > be my first significant contribution. I have developed a prototype of > the solution that seems to work well enough to compile and run CPU2017 > intrate benchmarks correctly. I am now in the process of running the > full suite. Feedback would be appreciated. > > Here's an overview of how it works: > > ipa-initcall-cp collects all variables with static lifetime that contain > only a single constant write. Then, for each read of the variable, we > determine (statically) if the write occurs before read. In order to do > this, we use both the dominators graph and the static call graph. If the > write occurs before all reads, then we can safely substitute the read > with the constant being written to the variable. ipa-initcall-cp works > across function calls so the read and write do not need to occur on the > same function.
I've had a quick look and stumbled across the following issues that make adoption highly unlikely: - the pass is a simple IPA pass - it needs to disable IPA CP for some reason - it looks quite heavy-weight for the simple transform it does (targeting bechmarks) Now, the specific transform should be done as true IPA pass and I think most of the requirements are already met by the IPA reference pass. IPA reference local analysis would need to be changed to record whether stores to a variable dominate loads and all calls local to a function [alternatively record a bounded vector of called functions before such store]. At WPA time this information can be propagated and at transform time the value replacement can happen. > There are some issues which still need to be addressed, particularly, > ipa-initcall-cp is at the moment just a prototype and as such it will > stream in functions and modify them during WPA. I would like to fix > this, however I am not sure how to properly use clones when modifying > the function body. I'm not sure why you are cloning functions at all here - you do not seem to consider the case where only a subset of the program flow dominates a store to the respective variable? Richard. > I have tested this against applied my patch to GCC version 10.1. If you > have any questions, comments, let me know. > > [0] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92538