On Fri, Oct 2, 2015 at 12:24 PM, James Greenhalgh
wrote:
> On Fri, Oct 02, 2015 at 11:06:53AM +0100, Marek Polacek wrote:
>> On Fri, Oct 02, 2015 at 11:58:42AM +0200, Jakub Jelinek wrote:
>> > On Fri, Oct 02, 2015 at 11:45:08AM +0200, Richard Biener wrote:
>> > > > Note, I won't have time to work
On Fri, Oct 02, 2015 at 11:24:32AM +0100, James Greenhalgh wrote:
> > > PR67815.
> >
> > James, are you interested in this one, or would you prefer if I take it?
>
> I'm happy either way.
>
> I haven't looked at reassoc before, so I don't know my way wround it, and
> I'm out of office for a wedd
On Fri, Oct 02, 2015 at 11:06:53AM +0100, Marek Polacek wrote:
> On Fri, Oct 02, 2015 at 11:58:42AM +0200, Jakub Jelinek wrote:
> > On Fri, Oct 02, 2015 at 11:45:08AM +0200, Richard Biener wrote:
> > > > Note, I won't have time to work on this in the near future (OpenMP work
> > > > still on the pl
On Fri, Oct 02, 2015 at 11:58:42AM +0200, Jakub Jelinek wrote:
> On Fri, Oct 02, 2015 at 11:45:08AM +0200, Richard Biener wrote:
> > > Note, I won't have time to work on this in the near future (OpenMP work
> > > still on the plate), so if James (or anyone else?) has time for that, it
> > > would b
On Fri, Oct 02, 2015 at 11:45:08AM +0200, Richard Biener wrote:
> > Note, I won't have time to work on this in the near future (OpenMP work
> > still on the plate), so if James (or anyone else?) has time for that, it
> > would be greatly appreciated.
>
> So maybe just open an enhancement bug for n
On Fri, Oct 2, 2015 at 11:27 AM, Jakub Jelinek wrote:
> On Fri, Oct 02, 2015 at 11:10:58AM +0200, Richard Biener wrote:
>> > BTW, it seems wrf also in many places uses MAX
>> > or MIN (always in pairs), would that be also
>> > something to optimize?
>>
>> Hmm, we'll already CSE copysign so the q
On Fri, Oct 02, 2015 at 11:10:58AM +0200, Richard Biener wrote:
> > BTW, it seems wrf also in many places uses MAX
> > or MIN (always in pairs), would that be also
> > something to optimize?
>
> Hmm, we'll already CSE copysign so the question is how to optimize
> tem1 = MAX ; tem2= MIN ; Turn t
On Fri, Oct 2, 2015 at 11:03 AM, Jakub Jelinek wrote:
> On Fri, Oct 02, 2015 at 10:18:01AM +0200, Richard Biener wrote:
>> On Thu, Oct 1, 2015 at 8:36 PM, Jakub Jelinek wrote:
>> > On Thu, Oct 01, 2015 at 02:57:15PM +0100, James Greenhalgh wrote:
>> >> 2015-10-01 James Greenhalgh
>> >>
>> >>
On Fri, Oct 02, 2015 at 10:18:01AM +0200, Richard Biener wrote:
> On Thu, Oct 1, 2015 at 8:36 PM, Jakub Jelinek wrote:
> > On Thu, Oct 01, 2015 at 02:57:15PM +0100, James Greenhalgh wrote:
> >> 2015-10-01 James Greenhalgh
> >>
> >> * match.pd (mult (COPYSIGN:s real_onep @0) @1): New simpl
On Thu, Oct 1, 2015 at 8:36 PM, Jakub Jelinek wrote:
> On Thu, Oct 01, 2015 at 02:57:15PM +0100, James Greenhalgh wrote:
>> 2015-10-01 James Greenhalgh
>>
>> * match.pd (mult (COPYSIGN:s real_onep @0) @1): New simplifier.
>
> Also, please note that
> + wide_int m = wi::min_value (TYP
On Thu, Oct 01, 2015 at 02:57:15PM +0100, James Greenhalgh wrote:
> 2015-10-01 James Greenhalgh
>
> * match.pd (mult (COPYSIGN:s real_onep @0) @1): New simplifier.
Also, please note that
+ wide_int m = wi::min_value (TYPE_PRECISION (type), SIGNED);
+ tree tt
+ = build_nonst
Hi,
On Thu, 1 Oct 2015, Joseph Myers wrote:
> On Thu, 1 Oct 2015, Michael Matz wrote:
>
> > both cases. The catch is that strictly speaking (NaN * -1.0) needs to
> > deliver NaN, not -NaN (operations involving quiet NaNs need to provide
> > one of the input NaNs as result), and here both are
Hi,
On Thu, 1 Oct 2015, Jakub Jelinek wrote:
> But if x is a sNaN, then the multiplication will throw an exception, while
> the transformed operation will not.
Hmm, that's right, silly me.
> So perhaps it should be guarded by
> !HONOR_SNANS (TYPE_MODE (type))
> ?
That makes sense, yes.
Ciao,
On Thu, 1 Oct 2015, Michael Matz wrote:
> both cases. The catch is that strictly speaking (NaN * -1.0) needs to
> deliver NaN, not -NaN (operations involving quiet NaNs need to provide
> one of the input NaNs as result), and here both are not equivalent. OTOH
> the sign of NaNs isn't specifie
On Thu, Oct 01, 2015 at 05:43:15PM +0200, Michael Matz wrote:
> Hi,
>
> On Thu, 1 Oct 2015, James Greenhalgh wrote:
>
> > > > x * copysign (1.0, y)
> > > >
> > > > x ^ (y & (1 << sign_bit_position))
> > >
> > > Also I think this can only be done for finite and non trapping types.
> >
> > Th
Hi,
On Thu, 1 Oct 2015, James Greenhalgh wrote:
> > > x * copysign (1.0, y)
> > >
> > > x ^ (y & (1 << sign_bit_position))
> >
> > Also I think this can only be done for finite and non trapping types.
>
> That may be well true, I swithered either way and went for no checks,
> but I'd happi
> On Oct 1, 2015, at 7:51 AM, James Greenhalgh wrote:
>
> On Thu, Oct 01, 2015 at 03:28:22PM +0100, pins...@gmail.com wrote:
>>>
>>> On Oct 1, 2015, at 6:57 AM, James Greenhalgh
>>> wrote:
>>>
>>>
>>> Hi,
>>>
>>> If it is cheap enough to treat a floating-point value as an integer and
>>> t
On Thu, Oct 01, 2015 at 03:28:22PM +0100, pins...@gmail.com wrote:
> >
> > On Oct 1, 2015, at 6:57 AM, James Greenhalgh
> > wrote:
> >
> >
> > Hi,
> >
> > If it is cheap enough to treat a floating-point value as an integer and
> > to do bitwise arithmetic on it (as it is for AArch64) we can r
>
> On Oct 1, 2015, at 6:57 AM, James Greenhalgh wrote:
>
>
> Hi,
>
> If it is cheap enough to treat a floating-point value as an integer and
> to do bitwise arithmetic on it (as it is for AArch64) we can rewrite:
>
> x * copysign (1.0, y)
>
> as:
>
> x ^ (y & (1 << sign_bit_position))
W
Hi,
If it is cheap enough to treat a floating-point value as an integer and
to do bitwise arithmetic on it (as it is for AArch64) we can rewrite:
x * copysign (1.0, y)
as:
x ^ (y & (1 << sign_bit_position))
This patch implements that rewriting rule in match.pd, and a testcase
expecting th
20 matches
Mail list logo