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