Re: RFC: extend cprop_hardreg into a global pass

[Steven Bosscher <stevenb dot gcc at gmail dot com>]

On Wed, Jul 25, 2012 at 3:35 AM, Bin.Cheng <amker.cheng@gmail.com> wrote:
> On Wed, Jul 25, 2012 at 2:14 AM, Steven Bosscher <stevenb.gcc@gmail.com> wrote:
>> Bin Cheng wrote:
>>> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44025
>>
>> You could foster-parent and fix the attached patch to address this issue.
>> (I'm not interested in pursuing this further myself.)
>
> Thanks for your comments.
> I haven't look into the patch yet,

If you will look at it, please make sure to add a free_dominance_info call:

+  /* Finalize and clean up.  */
+  fini_walk_dominator_tree (&walk_data);
+
+  /* We must free this, or cfgcleanup barfs.  */
+  free_dominance_info (CDI_DOMINATORS);
+

You could also add support for unpropagating constants found in
REG_EQUIV notes (usually those are the expensive ones), and for
related constants (e.g. "constval+{1,2,4,8}" and
"constval<<{-3,-2,-1,1,2,3}").

You probably also would want to put the pass in its own file and add
an rtl_opt_pass for it (I hacked it at the bottom of cse.c because I
didn't want to change Makefile.in etc.).

> but doing it before ira may
> increase register pressure, while on the other hand, loading simple
> constant is trivial operation on modern machines.

I don't think register pressure is an issue as long as the equivalence
of the register to a constant is known and the register allocator can
re-materialize it.

If the equivalence is lost, or RA decides that spilling is cheaper
than re-materializing, then this unpropagation idea will probably be
an overall loss.

I didn't investigate any of this. Writing this whole pass tool ~30
minutes, I just wanted to show how easy it can be to write a simple
experimental GCC pass. If you disable the un-propagation itself (i.e.
the validate_change call), you can at least use the pass to see how
often opportunities for this kind of transformation arise in
real-world software, and decide where to spend your effort most
efficiently.

For the other PR you mentioned, that looks like a register allocation
regression, that should be addresses in IRA rather than in regcprop.

Ciao!
Steven