[RFC] - Regression exposed by recent change to compress_float_constant

Dale Johannesen dalej@apple.com
Wed Aug 10 21:34:00 GMT 2005


On Aug 10, 2005, at 12:43 PM, Fariborz Jahanian wrote:

> Following patch has exposed an optimization shortcoming:
>
> 2005-07-12  Dale Johannesen  <dalej@apple.com>
>
>         * expr.c (compress_float_constant):  Add cost check.
>         * config/rs6000.c (rs6000_rtx_cost):  Adjust FLOAT_EXTEND cost.
>
> This patch results in generating worse code for the following test 
> case:
>
> 1) Test case:
>
> struct S {
>         float d1, d2, d3;

I believe you mean double not float; the RTL snippets you give indicate 
this.

> (insn 12 7 13 0 (set (reg:SF 59)
>         (mem/u/i:SF (symbol_ref/u:SI ("*LC0") [flags 0x2]) [0 S4 
> A32])) -1 (nil)
>     (nil))
>
> (insn 13 12 14 0 (set (mem/s/j:DF (reg/f:SI 58 [ D.1929 ]) [0 
> <result>.d1+0 S8 A32])
>         (float_extend:DF (reg:SF 59))) -1 (nil)
>     (nil))

However, if you try your example with float as given, you see it does 
not do a
direct store of constant 0 with or without the compress_float patch.  
IMO the
compress_float patch does not really have anything to do with this 
problem;
before this patch the double case was working well by accident, my patch
exposed a problem farther downstream, which was always there for the 
float
case.

When I put that patch in, rth remarked:

While I certainly wouldn't expect fold_rtx to find out about this
all by itself, I'd have thought that there would have been a
REG_EQUIV or REG_EQUAL note that indicates that the end result is
the constant (const_double:DF 1.0), and use that in any simplification.

Indeed there is no such note, and I suspect adding it somewhere 
(expand?) would fix this.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: text/enriched
Size: 1708 bytes
Desc: not available
URL: <https://gcc.gnu.org/pipermail/gcc/attachments/20050810/43b470dd/attachment.bin>


More information about the Gcc mailing list