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

Reply via email to