This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [RFC] - Regression exposed by recent change to compress_float_constant


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:

<x-tad-bigger>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.

</x-tad-bigger>
Indeed there is no such note, and I suspect adding it somewhere (expand?) would fix this.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]