Re: how to fix anti-optimization?

[Dale Johannesen <dalej@apple.com>]

On Wednesday, September 12, 2001, at 03:14 PM, Richard Henderson wrote:

> On Wed, Sep 12, 2001 at 11:35:00AM -0700, dalej@apple.com wrote:
>> The substitution is done in the ARRAY_REF case of expr.c:expand_expr().
>> It looks like I could hack this by setting TREE_SIDE_EFFECTS on FP
>> constants, but surely that's not the right way to do it.  Any better 
>> ideas?
>
> If the constant is not LEGITIMATE_CONSTANT_P, make the ARRAY_REF
> expand as normal, then tag the resulting memory reference with a
> REG_EQUAL note containing the known constant.

Some problems with this.  First, I discover that LEGITIMATE_CONSTANT_P on 
rs6000 accepts some FP consts, after checking to see whether they can be 
*moved* into int regs with 1 instruction per word.  That's not right, is 
it?  It doesn't match the documentation of LEGITIMATE_CONSTANT_P.  I 
suppose the reason is so that here
    double x= 5.0;  double y = 3.172348904532;
the store into x can be done with 2 int stores, while the store into y 
uses lfd/std.  However, that happens regardless of LEGITIMATE_CONSTANT_P, 
by virtue of the 'G' constraint.  OK to change LEGITIMATE_CONSTANT_P to 
reject all FP consts (assuming bootstrap works)?

So after doing that locally I was able to get the suggestion above to work.
   Unfortunately, the effect of the REG_EQUAL note is to cause another copy 
of the constant to be substituted for the array memref later in the 
proceedings; it does make the constant folding work though.

const double Prescale[] = { 3.0, 5.0 };
     bar(Prescale[0], Prescale[1], Prescale[0]*Prescale[1]);

For this, the RT is to load from the array for the 1st two parameters, and 
to do the multiplication at compile time, loading the resulting constant 
15.0 from a new memory loc.  So far I haven't been able to get that.