On Fri, Oct 10, 2014 at 3:27 PM, Vincent Lefevre wrote:
> On 2014-10-10 11:07:52 +0200, Jakub Jelinek wrote:
>> Though, is such optimization desirable even for fast-math?
>
> I wonder whether fast-math has a well-defined spec, but it should be
> noted that because of possible cancellations, even i
On 2014-10-10 11:07:52 +0200, Jakub Jelinek wrote:
> Though, is such optimization desirable even for fast-math?
I wonder whether fast-math has a well-defined spec, but it should be
noted that because of possible cancellations, even if the final result
is a float, it may be better to keep intermedi
On Thu, Oct 09, 2014 at 03:55:34PM -0700, Steve Ellcey wrote:
> On Thu, 2014-10-09 at 19:50 +, Joseph S. Myers wrote:
> > On Thu, 9 Oct 2014, Steve Ellcey wrote:
> >
> > > Do you know which pass does the simple
> > > '(float)function((double)float_val)' demotion? Maybe that would be a
> > > g
On Fri, Oct 10, 2014 at 12:55 AM, Steve Ellcey wrote:
> On Thu, 2014-10-09 at 19:50 +, Joseph S. Myers wrote:
>> On Thu, 9 Oct 2014, Steve Ellcey wrote:
>>
>> > Do you know which pass does the simple
>> > '(float)function((double)float_val)' demotion? Maybe that would be a
>> > good place to
On Thu, 2014-10-09 at 19:50 +, Joseph S. Myers wrote:
> On Thu, 9 Oct 2014, Steve Ellcey wrote:
>
> > Do you know which pass does the simple
> > '(float)function((double)float_val)' demotion? Maybe that would be a
> > good place to extend things.
>
> convert.c does such transformations. May
On Thu, 9 Oct 2014, Steve Ellcey wrote:
> Do you know which pass does the simple
> '(float)function((double)float_val)' demotion? Maybe that would be a
> good place to extend things.
convert.c does such transformations. Maybe the transformations in there
could move to the match-and-simplify in
On October 9, 2014 8:40:49 PM CEST, Andrew Pinski wrote:
>On Thu, Oct 9, 2014 at 11:32 AM, Steve Ellcey wrote:
>> On Thu, 2014-10-09 at 11:27 -0700, Andrew Pinski wrote:
>>
>>> > Is there a reason why GCC couldn't (under -ffast-math) call the
>single
>>> > precision routines for the first case?
>
On Thu, Oct 9, 2014 at 11:32 AM, Steve Ellcey wrote:
> On Thu, 2014-10-09 at 11:27 -0700, Andrew Pinski wrote:
>
>> > Is there a reason why GCC couldn't (under -ffast-math) call the single
>> > precision routines for the first case?
>>
>> There is no reason why it could not. The reason why it doe
On Thu, 2014-10-09 at 11:27 -0700, Andrew Pinski wrote:
> > Is there a reason why GCC couldn't (under -ffast-math) call the single
> > precision routines for the first case?
>
> There is no reason why it could not. The reason why it does not
> currently is because there is no pass which does the
On Thu, Oct 9, 2014 at 11:23 AM, Steve Ellcey wrote:
> I have a -ffast-math (missing?) optimization question. I noticed on MIPS
> that if I compiled:
>
> #include
> extern x;
> void foo() { x = sin(log(x)); }
>
> GCC will extend 'x' to double precision, call the double pr
I have a -ffast-math (missing?) optimization question. I noticed on MIPS
that if I compiled:
#include
extern x;
void foo() { x = sin(log(x)); }
GCC will extend 'x' to double precision, call the double precision log and sin
functions and then truncate the result to single
11 matches
Mail list logo