[RFC] - Regression exposed by recent change to compress_float_constant

[Dale Johannesen]

Fariborz is having trouble with his mailer and has asked me to forward 
his response.

On Aug 10, 2005, at 2:35 PM, Dale Johannesen wrote:
> 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.

Yes, it is double. Copied the wrong test.

>> (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;

Yes. Title says Regression 'exposed' by .... But as my email pointed 
out, float_extend is substituted in cse. So, this is another case of 
change in rtl pattern breaks an optimization down the road. I don't 
know if this is a regression or exposition of a lurking bug.

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

Yes. I mentioned that in my email.

- fariborz

> 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: 2333 bytes
Desc: not available
URL: <https://gcc.gnu.org/pipermail/gcc/attachments/20050811/42b9d4e3/attachment.bin>