On Sunday 08 May 2005 21:00, Richard Henderson wrote:
> On Sun, May 08, 2005 at 04:33:28PM +0200, Steven Bosscher wrote:
> > Can we expose this kind of address arithmetic to the tree
> > optimizers? Should we?
>
> No and no.
Clear enough :-)
> I've always believed that we'd be keeping an rtl gcse
> pass exactly for the reason of address arithmetic.
Right. That makes life easier here, thanks.
As a related issue, there is still this odd interaction between RTL
GCSE-PRE and CPROP that should be fixed. Example for ppc32 for a set
of cc1-i files:
$ grep ^CPROP *.gcse | grep "pass 1" | grep -v "0 global const props" > out1
$ grep ^CPROP *.gcse | grep "pass 2" | grep -v "0 global const props" > out2
$ wc out1 out2
32 768 5003 out1
3086 74064 493451 out2
3118 74832 498454 total
In other words, after GCSE PRE, suddenly GCSE CPROP needs to do (or
at least, is doing) a lot of work. Apparently it is propagating lots
of high parts of constant addresses:
$ grep "^GLOBAL CONST-PROP" *.gcse | wc
22579 401643 3900039
$ grep "^GLOBAL CONST-PROP" *.gcse | grep symbol_ref | wc
22260 397496 3866741
$ grep "^GLOBAL CONST-PROP" *.gcse | grep symbol_ref | grep -vw high | wc
2 32 295
A test case that shows what is going on is this:
extern char *x;
void
foo (char *a, char *b)
{
if (!x)
x = a;
else
x = b;
}
The first RTL CPROP pass does nothing. Then PRE hoists a constant of
the form "(high:SI (symbol_ref:SI ("x") [flags 0x2] <var_decl 0x400a7690 x>))"
and CPROP2 undoes it. (I have no idea yet to fix this, but my guess
is that it's just the same problem as the one I reported in PR16967...)
Gr.
Steven
