This is the mail archive of the gcc-patches@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: [PATCH] Recognize sqrt(1.0/x) as rsqrt.d on MIPS4


Roger Sayle <roger@eyesopen.com> writes:

> On Tue, 10 Aug 2004, Richard Sandiford wrote:
>> But don't you think that's the right way to go?
>>
>> I object to the patch you posted.  This seems no better than having
>> each backend match (minus ... (const_int X)) as an alternative to
>> (plus ... (const_int -X)), etc.
>
> On balance, I think this patch (and its three new test cases)

This probably shows I've not been paying attention, but which new test
cases do you mean?  The MIPS patch itself didn't have any.

I'm just uneasy at seeing more uses of flag_unsafe_math_optimizations
creeping into the back-end.  I'd much rather the middle-end say what was
fair game and what wasn't, in the hope of presenting a more consistent,
cross-platform interface[*].  Perhaps we could have a rsqrt rtx code and
optab, and have the middle-end check whether that is available.

On the other hand, the wedge is already in the door given the existing
rsqrt pattern, so I suppose it's unfair of me to object.  Eric's already
approved the patch, so feel free to check it in.

Richard

  [*] I know there are cases when a back-end really does have to check
      flag_unsafe_math_optimizations, such as the MIPS port does for
      the SB-1 div.s workarounds.  But that seems like a different
      class of problem.


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