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