er [mailto:richard.guent...@gmail.com]
>> Sent: 19 August 2015 13:35
>> To: Richard Biener; David Sherwood; GCC Patches; Richard Sandiford
>> Subject: Re: [PING][Patch] Add support for IEEE-conformant versions of
>> scalar fmin* and fmax*
>>
>> On Wed, Aug 1
Message-
> From: Richard Biener [mailto:richard.guent...@gmail.com]
> Sent: 19 August 2015 13:35
> To: Richard Biener; David Sherwood; GCC Patches; Richard Sandiford
> Subject: Re: [PING][Patch] Add support for IEEE-conformant versions of scalar
> fmin* and fmax*
>
> On
On Mon, 14 Sep 2015, Richard Biener wrote:
> To make progess here I think adding new optabs is fine. So can you
> split out that part and implement builtin expanders
> for fmin/max instead?
>
> Btw, FMIN/MAX_EXPR are not commutative AFAIK because of behavior for
> fmax (-NaN, NaN)
> vs. fmax (Na
FMIN_EXPR.
> * doc/md.texi: Add fmin and fmax patterns.
> gcc/testsuite
> * gcc.target/aarch64/fmaxmin.c: New test.
> * gcc.target/arm/fmaxmin.c: New test.
>
>
>> -Original Message-
>> From: Richard Biener [mailto:richard.guent...@gmail.com]
>>
chard.guent...@gmail.com]
> Sent: 19 August 2015 14:41
> To: Richard Biener; David Sherwood; GCC Patches; Richard Sandiford
> Subject: Re: [PING][Patch] Add support for IEEE-conformant versions of scalar
> fmin* and fmax*
>
> On Wed, Aug 19, 2015 at 3:06 PM, Richard Sandiford
Richard Biener writes:
> BTW, in addition to errno math there is rounding math where we rely on
> virtual operands to not mess with ordering.
But you know what I'm going to say to that. Rounding affects arithmetic
just as much as things like pow(). (And also doesn't affect min/max.)
Richard
On Wed, 19 Aug 2015, Richard Biener wrote:
> As an additional point for many math functions we have to support errno
> which means, like, BUILT_IN_SQRT can be rewritten to SQRT_EXPR
> only if -fno-math-errno is in effect. But then code has to handle
I'd say that for functions like that (which ca
On August 19, 2015 5:05:01 PM GMT+02:00, Michael Matz wrote:
>Hi,
>
>On Wed, 19 Aug 2015, Richard Biener wrote:
>
>> I think tree_code is 64bits now.
>
>Huh? No; it's 16 bit since 8 bit run out.
Err, that's what I was trying to say...
16bits, obviously.
BTW, in addition to errno math there is r
Hi,
On Wed, 19 Aug 2015, Richard Biener wrote:
> I think tree_code is 64bits now.
Huh? No; it's 16 bit since 8 bit run out.
Ciao,
Michael.
On Wed, Aug 19, 2015 at 3:06 PM, Richard Sandiford
wrote:
> Richard Biener writes:
>> As an additional point for many math functions we have to support errno
>> which means, like, BUILT_IN_SQRT can be rewritten to SQRT_EXPR
>> only if -fno-math-errno is in effect. But then code has to handle
>>
Richard Biener writes:
> As an additional point for many math functions we have to support errno
> which means, like, BUILT_IN_SQRT can be rewritten to SQRT_EXPR
> only if -fno-math-errno is in effect. But then code has to handle
> both variants for things like constant folding and expression com
On Wed, Aug 19, 2015 at 2:11 PM, Richard Sandiford
wrote:
> Richard Biener writes:
>> On Wed, Aug 19, 2015 at 11:54 AM, Richard Sandiford
>> wrote:
>>> Richard Biener writes:
On Tue, Aug 18, 2015 at 4:15 PM, Richard Sandiford
wrote:
> Richard Biener writes:
>> On Tue, Aug 18
Richard Biener writes:
> On Wed, Aug 19, 2015 at 11:54 AM, Richard Sandiford
> wrote:
>> Richard Biener writes:
>>> On Tue, Aug 18, 2015 at 4:15 PM, Richard Sandiford
>>> wrote:
Richard Biener writes:
> On Tue, Aug 18, 2015 at 1:07 PM, David Sherwood
> wrote:
>>> On Mon, Aug
On Wed, Aug 19, 2015 at 11:54 AM, Richard Sandiford
wrote:
> Richard Biener writes:
>> On Tue, Aug 18, 2015 at 4:15 PM, Richard Sandiford
>> wrote:
>>> Richard Biener writes:
On Tue, Aug 18, 2015 at 1:07 PM, David Sherwood
wrote:
>> On Mon, Aug 17, 2015 at 11:29 AM, David Sherwoo
Richard Biener writes:
> On Tue, Aug 18, 2015 at 4:15 PM, Richard Sandiford
> wrote:
>> Richard Biener writes:
>>> On Tue, Aug 18, 2015 at 1:07 PM, David Sherwood
>>> wrote:
> On Mon, Aug 17, 2015 at 11:29 AM, David Sherwood
> wrote:
> > Hi Richard,
> >
> > Thanks for the r
On Tue, Aug 18, 2015 at 4:15 PM, Richard Sandiford
wrote:
> Richard Biener writes:
>> On Tue, Aug 18, 2015 at 1:07 PM, David Sherwood
>> wrote:
On Mon, Aug 17, 2015 at 11:29 AM, David Sherwood
wrote:
> Hi Richard,
>
> Thanks for the reply. I'd chosen to add new express
Richard Biener writes:
> On Tue, Aug 18, 2015 at 1:07 PM, David Sherwood
> wrote:
>>> On Mon, Aug 17, 2015 at 11:29 AM, David Sherwood
>>> wrote:
>>> > Hi Richard,
>>> >
>>> > Thanks for the reply. I'd chosen to add new expressions as this seemed
>>> > more
>>> > consistent with the existing M
ainst a new tree code is that we'd have an awful
lot of similar codes when pushing other flag related IL specialities to actual
IL constructs. And we still need to find a consistent way to do that.
Richard.
> David.
>
>>
>> Richard.
>>
>> > Regards,
>> >
s. I thought for IEEE-compliant behaviour we just need to ensure
that for
each pair of elements if one element is a NaN we return the other one.
David.
>
> Richard.
>
> > Regards,
> > David.
> >
> >> -Original Message-
> >> From: Richard Bien
rect?)
Richard.
> Regards,
> David.
>
>> -Original Message-
>> From: Richard Biener [mailto:richard.guent...@gmail.com]
>> Sent: 13 August 2015 12:10
>> To: David Sherwood
>> Cc: GCC Patches
>> Subject: Re: [PING][Patch] Add support for IEEE-confor
x27;t seem very consistent.
Regards,
David.
> -Original Message-
> From: Richard Biener [mailto:richard.guent...@gmail.com]
> Sent: 13 August 2015 12:10
> To: David Sherwood
> Cc: GCC Patches
> Subject: Re: [PING][Patch] Add support for IEEE-conformant versions of scalar
>
On Thu, Aug 13, 2015 at 12:11 PM, David Sherwood wrote:
> Hi,
>
> Sorry to bother people again. Is this OK to go now?
Hmm, why don't you go the vectorized function call path for this,
implementing the builtin_vectorized_function target hook?
Richard.
> Thanks!
> David.
>
>> >
>> > > On Mon, 29
22 matches
Mail list logo