Law; GCC
> > Patches; Wilco Dijkstra; Michael Meissner; nd
> > Subject: RE: [PATCH][GCC][PATCHv3] Improve fpclassify w.r.t IEEE like
> > numbers in GIMPLE.
> >
> > On Wed, 23 Aug 2017, Tamar Christina wrote:
> >
> > > Hi Richard,
> > >
> > &g
GCC][PATCHv3] Improve fpclassify w.r.t IEEE like
> numbers in GIMPLE.
>
> On Wed, 23 Aug 2017, Tamar Christina wrote:
>
> > Hi Richard,
> >
> > Thanks for the feedback,
> >
> > >
> > > I think you should split up your work a bit. The piece
On Wed, 23 Aug 2017, Tamar Christina wrote:
> Hi Richard,
>
> Thanks for the feedback,
>
> >
> > I think you should split up your work a bit. The pieces from
> > fold_builtin_* you remove and move to lowering that require no control flow
> > like __builtin_isnan (x) -> x UNORD x should move to
Hi Richard,
Thanks for the feedback,
>
> I think you should split up your work a bit. The pieces from
> fold_builtin_* you remove and move to lowering that require no control flow
> like __builtin_isnan (x) -> x UNORD x should move to match.pd patterns (aka
> foldings that will then be applied
gt; Dijkstra; Michael Meissner; nd
> Subject: RE: [PATCH][GCC][PATCHv3] Improve fpclassify w.r.t IEEE like numbers
> in GIMPLE.
>
> > -Original Message-
> > From: Richard Biener [mailto:rguent...@suse.de]
> > Sent: 08 June 2017 19:23
> > To: Joseph Myers
> &g
sner; nd
> Subject: Re: [PATCH][GCC][PATCHv3] Improve fpclassify w.r.t IEEE like
> numbers in GIMPLE.
>
> On June 8, 2017 6:44:01 PM GMT+02:00, Joseph Myers
> wrote:
> >On Thu, 8 Jun 2017, Richard Biener wrote:
> >
> >> For a built-in this is generally valid. F
GCC][PATCHv3] Improve fpclassify w.r.t IEEE like
> numbers in GIMPLE.
>
> On June 8, 2017 6:44:01 PM GMT+02:00, Joseph Myers
> wrote:
> >On Thu, 8 Jun 2017, Richard Biener wrote:
> >
> >> For a built-in this is generally valid. For plain isnan it depends
> >o
Hi Tamar,
> I have reverted the patch in commit r 249050 until I can fix the late
> expansion
> and IBM long double issues.
thanks. Just for the record, Solaris/SPARC (also big-endian) was
affected as well:
https://gcc.gnu.org/ml/gcc-testresults/2017-06/msg00908.html
Rainer
-
>To: Christophe Lyon; Markus Trippelsdorf
> >Cc: Joseph Myers; Jeff Law; GCC Patches; Wilco Dijkstra;
> >rguent...@suse.de; Michael Meissner; nd
> >Subject: RE: [PATCH][GCC][PATCHv3] Improve fpclassify w.r.t IEEE like
> >numbers in GIMPLE.
> >
> &g
> Cc: Tamar Christina; Christophe Lyon; Markus Trippelsdorf; Jeffrey Law; Wilco
> Dijkstra; Michael Meissner; nd; GCC Patches
> Subject: Re: [PATCH][GCC][PATCHv3] Improve fpclassify w.r.t IEEE like
> numbers in GIMPLE.
>
> On Thu, 8 Jun 2017, David Edelsohn wrote:
>
> > Tamar
On Thu, 8 Jun 2017, David Edelsohn wrote:
> Tamar,
>
> This patch has caused a large number of new failures on AIX, including
> compiler ICEs.
It also caused ICEs building glibc for all powerpc configurations (i.e.,
configurations using IBM long double).
https://sourceware.org/ml/libc-testresu
Tamar,
This patch has caused a large number of new failures on AIX, including
compiler ICEs.
Thanks, David
On June 8, 2017 6:44:01 PM GMT+02:00, Joseph Myers
wrote:
>On Thu, 8 Jun 2017, Richard Biener wrote:
>
>> For a built-in this is generally valid. For plain isnan it depends
>on
>> what the standard says.
>>
>> You have to support taking the address of isnan anyway and thus
>> expanding to a l
On Thu, 8 Jun 2017, Richard Biener wrote:
> For a built-in this is generally valid. For plain isnan it depends on
> what the standard says.
>
> You have to support taking the address of isnan anyway and thus
> expanding to a library call in that case. Why doesn't that not work?
In the case o
t;To: Christophe Lyon; Markus Trippelsdorf
>Cc: Joseph Myers; Jeff Law; GCC Patches; Wilco Dijkstra;
>rguent...@suse.de; Michael Meissner; nd
>Subject: RE: [PATCH][GCC][PATCHv3] Improve fpclassify w.r.t IEEE like
>numbers in GIMPLE.
>
>Thanks, I'm looking at the failure.
>
de;
Michael Meissner; nd
Subject: RE: [PATCH][GCC][PATCHv3] Improve fpclassify w.r.t IEEE like numbers
in GIMPLE.
Thanks, I'm looking at the failure.
My final validate seems to have only run the GCC tests.
> -Original Message-
> From: Christophe Lyon [mailto:christophe.l...@li
eff Law; GCC Patches; Wilco Dijkstra;
> rguent...@suse.de; Michael Meissner; nd
> Subject: Re: [PATCH][GCC][PATCHv3] Improve fpclassify w.r.t IEEE like
> numbers in GIMPLE.
>
> On 8 June 2017 at 12:30, Markus Trippelsdorf
> wrote:
> > On 2017.01.19 at 18:20 +, Joseph
On 8 June 2017 at 12:30, Markus Trippelsdorf wrote:
> On 2017.01.19 at 18:20 +, Joseph Myers wrote:
>> On Thu, 19 Jan 2017, Tamar Christina wrote:
>>
>> > Hi Joseph,
>> >
>> > I made the requested changes and did a quick pass over the rest
>> > of the fp cases.
>>
>> I've no further comments,
On 2017.01.19 at 18:20 +, Joseph Myers wrote:
> On Thu, 19 Jan 2017, Tamar Christina wrote:
>
> > Hi Joseph,
> >
> > I made the requested changes and did a quick pass over the rest
> > of the fp cases.
>
> I've no further comments, but watch out for any related test failures
> being reporte
May 2, 2017 10:09 AM
To: Bernhard Reutner-Fischer; Joseph Myers
Cc: Jeff Law; Wilco Dijkstra; rguent...@suse.de; Michael Meissner; nd
Subject: Re: [PATCH][GCC][PATCHv3] Improve fpclassify w.r.t IEEE like numbers
in GIMPLE.
Ping.
Hi All,
Since this didn't manage to get in for GCC 7, I
On Mon, 23 Jan 2017, Tamar Christina wrote:
> In the testcase I've also had to remove `-funsafe-math-optimizations`
> because at least on AArch64 this sets the LZ bit in the FPCR which
> causes the fcmp to collapse small subnormal numbers to 0 and so iszero
> would fail.
That's not an appropri
imizations.
From: Joseph Myers
Sent: Thursday, January 19, 2017 6:20:35 PM
To: Tamar Christina
Cc: Jeff Law; GCC Patches; Wilco Dijkstra; rguent...@suse.de; Michael Meissner;
nd
Subject: Re: [PATCH][GCC][PATCHv3] Improve fpclassify w.r.t IEEE like numbers
in GIMPLE.
On Thu, 19 Jan 2
On Thu, 19 Jan 2017, Tamar Christina wrote:
> Hi Joseph,
>
> I made the requested changes and did a quick pass over the rest
> of the fp cases.
I've no further comments, but watch out for any related test failures
being reported.
--
Joseph S. Myers
jos...@codesourcery.com
; Michael Meissner;
nd
Subject: Re: [PATCH][GCC][PATCHv3] Improve fpclassify w.r.t IEEE like numbers
in GIMPLE.
On Thu, 19 Jan 2017, Tamar Christina wrote:
> > The old code set orig_arg before converting IBM long double to double.
> > Your code sets it after the conversion. The
On Thu, 19 Jan 2017, Tamar Christina wrote:
> > The old code set orig_arg before converting IBM long double to double.
> > Your code sets it after the conversion. The old code set min_exp based on
> > a string set from REAL_MODE_FORMAT (orig_mode)->emin - 1; your code uses
> > the adjusted mode.
ut then creating the real using
build_real (type, rmin) using the adjusted type, shouldn't it not be getting
truncated?
I've updated and attached the patch.
Tamar
From: Joseph Myers
Sent: Thursday, January 19, 2017 2:46:06 PM
To: Tamar Christina
On Thu, 19 Jan 2017, Tamar Christina wrote:
> > Also, I don't think the call to perform_ibm_extended_fixups in
> > is_subnormal is correct. Subnormal for IBM long double is *not* the same
> > as subnormal double high part. Likewise it's incorrect in is_normal as
> > well.
>
> The calls to is_ze
iszero and issubnormal.
Tamar.
From: Joseph Myers
Sent: Wednesday, January 18, 2017 5:05:07 PM
To: Jeff Law
Cc: Tamar Christina; GCC Patches; Wilco Dijkstra; rguent...@suse.de; Michael
Meissner; nd
Subject: Re: [PATCH][GCC][PATCHv3] Improve fpclassify w.r
On Wed, 18 Jan 2017, Joseph Myers wrote:
> Generally, I don't see tests added that these new functions are correct
> for float, double and long double, which would detect such issues if run
> for a target with IBM long double.
Specifically, I think gcc.dg/tg-tests.h should have tests added for
Also, I don't think the call to perform_ibm_extended_fixups in
is_subnormal is correct. Subnormal for IBM long double is *not* the same
as subnormal double high part. Likewise it's incorrect in is_normal as
well.
Generally, I don't see tests added that these new functions are correct
for flo
Since the patch adds new built-in functions __builtin_issubnormal and
__builtin_iszero, it also needs to update c-typeck.c:convert_arguments to
make those functions remove excess precision. This is mentioned in the
PRs 77925 and 77926 for addition of those functions (which as I noted in
!
Kind Regards,
Tamar
From: Joseph Myers
Sent: Thursday, December 15, 2016 7:03:27 PM
To: Tamar Christina
Cc: Jeff Law; GCC Patches; Wilco Dijkstra; rguent...@suse.de; Michael Meissner;
nd
Subject: Re: [PATCH][GCC][PATCHv3] Improve fpclassify w.r.t IEEE l
Subject: Re: [PATCH][GCC][PATCHv3] Improve fpclassify w.r.t IEEE like numbers
in GIMPLE.
Hi Jeff,
I wasn't sure if you saw the updated patch attached to the previous email or if
you just hadn't had the time to look at it yet.
Cheers,
Tamar
rs
Cc: GCC Patches; Wilco Dijkstra; rguent...@suse.de; Michael Meissner; nd
Subject: Re: [PATCH][GCC][PATCHv3] Improve fpclassify w.r.t IEEE like numbers
in GIMPLE.
On 12/15/2016 03:14 AM, Tamar Christina wrote:
>
>> On a high level, presumably there's no real value in keeping
On 12/15/2016 03:14 AM, Tamar Christina wrote:
On a high level, presumably there's no real value in keeping the old
code to "fold" fpclassify. By exposing those operations as integer
logicals for the fast path, if the FP value becomes a constant during
the optimization pipeline we'll see the r
s so far!
Kind Regards,
Tamar
From: Joseph Myers
Sent: Thursday, December 15, 2016 7:03:27 PM
To: Tamar Christina
Cc: Jeff Law; GCC Patches; Wilco Dijkstra; rguent...@suse.de; Michael Meissner;
nd
Subject: Re: [PATCH][GCC][PATCHv3] Improve fpclassify w.r.t IEEE like numbers
in GIMPL
On Thu, 15 Dec 2016, Tamar Christina wrote:
> > Note that on some systems we even disable 64bit floating point support.
> > I suspect this check needs a little re-thinking as I don't think that
> > checking for a specific UNITS_PER_WORD is correct, nor is checking the
> > width of the type. I'm n
> On a high level, presumably there's no real value in keeping the old
> code to "fold" fpclassify. By exposing those operations as integer
> logicals for the fast path, if the FP value becomes a constant during
> the optimization pipeline we'll see the reinterpreted values flowing
> into the new
On 11/25/2016 05:18 AM, Tamar Christina wrote:
Hi Joseph,
I have updated the patch with the changes,
w.r.t to the formatting, there are tabs there that seem to be rendered
at 4 spaces wide. In my editor setup at 8 spaces they are correct.
Various random comments, mostly formatting. I do think
][PATCHv3] Improve fpclassify w.r.t IEEE like numbers
in GIMPLE.
Ping?
Is there anything else I need to do for the patch or is it OK for trunk?
Just a note, it is in my queue of things to look at. GIven it was
posted well before stage1 close I think it deserves the opportunity to
move forward (even
; Michael
Meissner; nd
Subject: Re: [PATCH][GCC][PATCHv3] Improve fpclassify w.r.t IEEE like numbers
in GIMPLE.
Hi Joseph,
I have updated the patch with the changes,
w.r.t to the formatting, there are tabs there that seem to be rendered
at 4 spaces wide. In my editor setup at 8 spaces they are
Meissner; nd
Subject: Re: [PATCH][GCC][PATCHv3] Improve fpclassify w.r.t IEEE like numbers
in GIMPLE.
Hi Joseph,
I have updated the patch with the changes,
w.r.t to the formatting, there are tabs there that seem to be rendered
at 4 spaces wide. In my editor setup at 8 spaces they are correct
, November 24, 2016 6:28:18 PM
To: Tamar Christina
Cc: GCC Patches; Wilco Dijkstra; rguent...@suse.de; l...@redhat.com; Michael
Meissner; nd
Subject: Re: [PATCH][GCC][PATCHv3] Improve fpclassify w.r.t IEEE like numbers
in GIMPLE.
On Thu, 24 Nov 2016, Tamar Christina wrote:
> @@ -11499,6 +11503,53 @@
On Thu, 24 Nov 2016, Tamar Christina wrote:
> @@ -11499,6 +11503,53 @@ to classify. GCC treats the last argument as
> type-generic, which
> means it does not do default promotion from float to double.
> @end deftypefn
>
> +@deftypefn {Built-in Function} int __builtin_isnan (...)
> +This buil
:43 PM
To: Tamar Christina
Cc: GCC Patches; Wilco Dijkstra; rguent...@suse.de; l...@redhat.com; Michael
Meissner; nd
Subject: Re: [PATCH][GCC][PATCHv3] Improve fpclassify w.r.t IEEE like numbers
in GIMPLE.
On Fri, 11 Nov 2016, Tamar Christina wrote:
> is_infinite and is_zero have been crea
On Fri, 11 Nov 2016, Tamar Christina wrote:
> is_infinite and is_zero have been created. This patch also introduces two new
> intrinsics __builtin_iszero and __builtin_issubnormal.
And so the ChangeLog entry needs to include:
PR middle-end/77925
PR middle-end/77926
(in addition
Hi All,
This is v3 of the patch which adds an optimized route to the fpclassify builtin
for floating point numbers which are similar to IEEE-754 in format.
The patch has been rewritten to do it in GIMPLE instead of a fold. As part of
the implementation optimized versions of is_normal, is_subnorma
47 matches
Mail list logo