Re: [RFC & patch]: Fix PR27277

[Ian Lance Taylor <ian at airs dot com>]

Uros Bizjak <ubizjak@gmail.com> writes:

> Standard i387 constant load instructions (fldz, fld1, ...) are not
> generated anymore with latest gcc, even for simple testcases like:
> 
> double test(void)
> {
>     return 1.0;
> }
> 
> The problem can be tracked to the interference between
> compress_load_constant () function in expr.c and legitimate_constant_p
> () function in the i386 backend. As legitimate_constant_p () declares
> all constants (including all FP constant) valid, it does not
> discriminate between "true" i387 constants, such as 0.0 and
> 1.0. According to this, compress_load_constant () function allways
> calculates the cost of loading the constant directly (oldcost) as the
> RTX cost of a simple SET pattern.
> The cost of the float_extend pattern (newcost) is calculated as a SET
> from a FLOAT_EXTEND pattern, which is in DFmode case  equals to 0. As
> the cost is further calculated from the sub-pattern, it is exactly the
> same, as in previous case, so oldcost == newcost.
> 
> The proposed patch changes the condition to generate a FLOAT_EXTEND
> pattern a bit. If oldcost == newcost, the FLOAT_EXTEND pattern is
> skipped, and original pattern is emitted. This solves all cases, where
> FLOAT_EXTEND  cost is defined as 0. The rationale for this change is
> in the fact, that non-extended loads are simpler to optimize, so we
> should emit FLOAT_EXTEND only in case when it _really_ improves
> something (according to rtx_costs).
> 
> Patch is bootstrapped on x86_64-pc-linux-gnu, regtesting is in
> progress (I do not expect any failures with this patch ;)
> 
> 2006-05-02  Uros Bizjak  <uros@kss-loka.si>
> 
>     PR target/27277
>     * expr.c (compress_float_constant): Do not emit move as an
>     extension when oldcost == newcost.

I can't see why it is correct to change the target independent code
here.  This seems like something that should be handled in the target
costs.

The whole point of compress_float_constant is to compress float
constants when it makes sense.  The assumption is that it makes sense
to do so whenever it is not more expensive to do so.  That's because
it's normally easier to manipulate a smaller value.  That seems like a
good general assumption which we do not want to change.

The i386 floating point model is relatively unusual.  Therefore it
seems to me that this is a special case which is best handled in the
i386 backend rather than in generic code.

In particular, a FLOAT_EXTEND of a magic constant like 0.0 would seem
to be more expensive than a SET of that same constant, and the i386
backend should reflect that.

Ian