Hi,

I have looked at the GCSE CPROP passes with CSE path following
disabled ("-O1 -fgcse --param max-cse-path-length=1").  The input
code are the cc1-i files from 20040726 (with checking enabled).

Maybe not really a surprise: Roughly 2/3 of the constants that
GCSE CPROP propagates are symbol_refs or something based on that:

$ grep "^GLOBAL CONST-PROP" *.gcse | wc
    389    6087   54479
$ grep "^GLOBAL CONST-PROP" *.gcse | grep symbol_ref | wc
    239    4137   37968

(FWIW this is in 571 cc1-i files for a total of 2309872 lines of
assembler outout)

As an example, here is a test case:

---------------------------
struct reload
{
  char * in;
  int pad[3];
  int mode;
};

extern struct reload rld[180];
extern unsigned char hard_regno_nregs[180];
extern int foo (int);

int
allocate_reload_reg2 (int r)
{
  int pass;

  for (pass = 0; pass < 2; pass++)
    {
      if (foo (rld[r].mode))
        {
          int nr = hard_regno_nregs[rld[r].mode];

          if (nr == 1)
            break;
        }
    }

  return foo (r);
}
---------------------------

Interesting detail: of those 239, 125 are addresses of things based
on "rld" in reload and reload1, e.g. for the test case (prettified ;-):

reload1.c.05.gcse:GLOBAL CONST-PROP:
Replacing reg 68 in insn 40 with constant
(const:DI (plus:DI (symbol_ref:DI ("rld") [flags 0x40] <var_decl 0x2a95a2add0 
rld>)
                   (const_int 16 [0x10])))

There are also a bunch of "naked" symbol_refs (ie. not wrapped
in "(const (...))") that are propagated as constants.  Some of
them could be propagated with an extended basic block CSE/CPROP
pass, but some of them are "real" global constants that we don't
propagate when I disable global GCSE CPROP.

Can we expose this kind of address arithmetic to the tree
optimizers?  Should we?

For some of the other constant propagations that RTL GCSE does,
I have filed PR21451.  I also found a few where expanding a tail
call exposed new constants, more about that in a minute.

Gr.
Steven


Reply via email to