public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Wilco Dijkstra <Wilco.Dijkstra@arm.com>
To: Tamar Christina <Tamar.Christina@arm.com>,
	Joseph Myers	<joseph@codesourcery.com>
Cc: GCC Patches <gcc-patches@gcc.gnu.org>,
	"jakub@redhat.com"	<jakub@redhat.com>,
	"rguenther@suse.de" <rguenther@suse.de>,
	"law@redhat.com"	<law@redhat.com>, nd <nd@arm.com>
Subject: Re: [PATCH] Optimise the fpclassify builtin to perform integer operations when possible
Date: Thu, 15 Sep 2016 11:21:00 -0000	[thread overview]
Message-ID: <AM5PR0802MB261017887DACFFCC102AB3F483F00@AM5PR0802MB2610.eurprd08.prod.outlook.com> (raw)
In-Reply-To: <470b48c8-5ed9-cc23-f6f5-a87fc9e0bc52@arm.com>

Tamar Christina wrote:
> On 13/09/16 13:43, Joseph Myers wrote:
> > On Tue, 13 Sep 2016, Tamar Christina wrote:
>>
> >> On 12/09/16 23:33, Joseph Myers wrote:
> >>> Why is this boolean false for ieee_quad_format, mips_quad_format and
> >>> ieee_half_format?  They should meet your description (even if the x86 /
> >>> m68k "extended" formats don't because of the leading mantissa bit being
> >>> set for infinities).
> >>>
> >> Ah, I played it a bit too safe there. I will change this and do some
> >> re-testing and update the patch.
> > It occurred to me that there might be an issue with your approach of
> > overlaying the floating-point value with a single integer, when the quad
> > formats are used on 32-bit systems where TImode isn't fully supported as a
> > scalar mode.  However, if that's an issue the answer isn't to mark the
> > formats as non-IEEE, it's to support ORing together the relevant parts of
> > multiple words when determining whether the mantissa is nonzero (or some
> > equivalent logic).
> >
> I have been trying to reproduce this on the architectures I have access to
> but have been unable to so far. In practice if this does happen though 
> isn't it the fault of the system for advertising partial TImode support and 
> support of IEEE types?
>
> It seems to me that in order for me to be able to do this fpclassify 
> would incur a rather large costs in complexity. Also wouldn't this be problematic 
> for other functions as well such as expand_builtin_signbit?

Yes, if there are targets which don't implement TImode operations then surely
they should be automatically split into DImode operations before or during Expand?
GCC's implementation of types larger than the register int type is generally extremely
poor as it is missing such an expansion (practically all compilers do this), so this
would improve things significantly.

So for now it would seem best to keep the boolean false for quad formats on 32-bit
targets.

Wilco

  reply	other threads:[~2016-09-15 11:01 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-09-12 16:21 Tamar Christina
2016-09-12 22:33 ` Joseph Myers
2016-09-13 12:25   ` Tamar Christina
2016-09-12 22:41 ` Joseph Myers
2016-09-13 12:30   ` Tamar Christina
2016-09-13 12:44     ` Joseph Myers
2016-09-15  9:08       ` Tamar Christina
2016-09-15 11:21         ` Wilco Dijkstra [this message]
2016-09-15 12:56           ` Joseph Myers
2016-09-15 13:05         ` Joseph Myers
2016-09-12 22:49 ` Joseph Myers
2016-09-13 12:33   ` Tamar Christina
2016-09-13 12:48     ` Joseph Myers
2016-09-13  8:58 ` Jakub Jelinek
2016-09-13 16:16   ` Jeff Law
2016-09-14  8:31     ` Richard Biener
2016-09-15 16:02       ` Jeff Law
2016-09-15 16:28         ` Richard Biener
2016-09-16 19:53 ` Jeff Law
2016-09-20 12:14   ` Tamar Christina
2016-09-20 14:52     ` Jeff Law
2016-09-20 17:52       ` Joseph Myers
2016-09-21  7:13       ` Richard Biener
2016-09-19 22:43 ` Michael Meissner
     [not found]   ` <41217f33-3861-dbb8-2f11-950ab30a7021@arm.com>
2016-09-20 21:27     ` Michael Meissner
2016-09-21  2:05       ` Joseph Myers
2016-09-21  8:32         ` Richard Biener
2016-09-12 17:24 Moritz Klammler
2016-09-12 20:08 ` Andrew Pinski
2016-09-13 12:16 Wilco Dijkstra
2016-09-13 16:10 ` Joseph Myers
2016-09-21 14:51 ` Richard Earnshaw (lists)

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=AM5PR0802MB261017887DACFFCC102AB3F483F00@AM5PR0802MB2610.eurprd08.prod.outlook.com \
    --to=wilco.dijkstra@arm.com \
    --cc=Tamar.Christina@arm.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=jakub@redhat.com \
    --cc=joseph@codesourcery.com \
    --cc=law@redhat.com \
    --cc=nd@arm.com \
    --cc=rguenther@suse.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).