Re: [PATCH] Optimise the fpclassify builtin to perform integer operations when possible

[Tamar Christina <tamar.christina@arm.com>]

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?