how to fix anti-optimization?

how to fix anti-optimization?

[dalej]

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

With -O1 or higher, gcc substitutes constants 3.0 and 5.0 for the array 
references.  This isn't a win on targets where the extra copies of these 
constants have to go in memory; you get an extra copy of the constants in 
data space.  Furthermore, on many targets, loading two FP constants 
individually requires computing two addresses, while loading them from the 
array requires only one address computation.  I see that this substitution 
would gain if some other optimizations happened to be doable as a result, 
e.g. constant folding, but I don't know how to determine that.

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?

Re: how to fix anti-optimization?

[Richard Henderson]

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.


r~

Re: how to fix anti-optimization?

[Dale Johannesen]

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.

Re: how to fix anti-optimization?

[David Edelsohn]

	GPRs can contain FP values.  FP constants can be loaded into GPRs.
Why isn't that be appropriate for LEGITIMATE_CONSTANT_P?  The macro is not
a question of which values are valid immediates for FPRs, but for any
registers.  easy_fp_constant values can be loaded directly into a GPR
representing SFmode or DFmode.  That is what the macro represents.

	Given your analysis, it looks like another GCC macro with
overloaded meanings used in too many instances.  Presumably we need the
macro to be expanded to have both a mode and a register class as
arguments.

	Maybe your change still is safe, but your interpretation of the
macro seems incomplete.

David

Re: how to fix anti-optimization?

[Richard Henderson]

On Fri, Sep 14, 2001 at 12:50:47PM -0700, Dale Johannesen wrote:
> 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?

Actually, it is.  While looking at a different problem, I remembered
that x86 does the same thing, since the best way to do "x = 2.0f" is
"movl $0x35800000,x".

I think you can just forget the LEGITIMATE_CONSTANT_P check.

> 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.

Hmm.  I'd expect cse_insn to be able to handle that...


r~

Re: how to fix anti-optimization?

[David Edelsohn]

	Is GCC's "cost" model involved anywhere in the path?  For PowerPC,
the cost of CONST_INT and CONST_DOUBLE are zero while FP memory costs are
bumped up.

David

Re: how to fix anti-optimization?

[Dale Johannesen]

On Thursday, September 13, 2001, at 10:50 AM, David Edelsohn wrote:

> 	Is GCC's "cost" model involved anywhere in the path?  For PowerPC,
> the cost of CONST_INT and CONST_DOUBLE are zero while FP memory costs are
> bumped up.

No, it isn't.  I looked at this; the substitution is done on trees, so 
this is too early, isn't it?  CONST_COSTS (etc.) works on rtl.
I appreciate the suggestions, and will be trying Richard Henderson's later 
today.

Re: how to fix anti-optimization?

[Richard Kenner]

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

    With -O1 or higher, gcc substitutes constants 3.0 and 5.0 for the array 
    references.  This isn't a win on targets where the extra copies of these 
    constants have to go in memory; you get an extra copy of the constants in 
    data space.

Only if it's no more complex an expression.  Consider Prescale[0]*Prescale[1].
It's *much* faster to do the folding in that case.