[PATCH]: Add __builtin_fpclassify()

[Richard Guenther]

On Wed, May 21, 2008 at 8:14 PM, Kaveh R. GHAZI <ghazi@caip.rutgers.edu> wrote:
> On Wed, 21 May 2008, Richard Guenther wrote:
>
>> On Wed, May 21, 2008 at 12:51 PM, Joseph S. Myers
>> <joseph@codesourcery.com> wrote:
>> > On Wed, 21 May 2008, Richard Guenther wrote:
>> >
>> >> Should we force the classification values to be constants?  You could do
>> >> so in check_builtin_function_arguments.  IMHO the folding of fp_classify
>> >> should be disabled for non-constant FP argument if we are optimizing for
>> >> size?  Or just disable it if the resulting expression does not fold to a
>> >> constant.
>> >
>> > I don't think it really matters whether we force the classification values
>> > to be constants, but probably best to do so given the intended use of this
>> > built-in is when they are constants.
>> >
>> > The built-in should always work regardless of whether optimizing for size
>> > of not.  This means that if you don't expand it inline then you need to
>> > expand it to call an appropriate libgcc function for the mode - but since
>> > you'd need to pass all the classification values to that function, this
>> > probably wouldn't help much if at all on code size.  So it might be better
>> > to expand it inline unconditionally, and leave it to C library headers to
>> > expand the macro to calling C library functions instead of the built-in if
>> > __OPTIMIZE_SIZE__ if the C library maintainers think that appropriate.
>>
>> Ok, I thought we just specify that the passed values need to match the
>> C library implementation so we can simply emit a call to fpclassify if
>> we choose to not fold.  Which makes me wonder if it is at all required
>> to provide a library implementation for this ... probably not.
>>
>> So I guess unconditionally folding is ok.
>> Richard.
>
> I agree that a (six argument) libgcc fallback doesn't make sense for -Os.
> And only the C library itself knows whether it implements the single
> argument version at all and what it's (they're) called (underscores, etc.)
> So I agree it's up to the header implementation to possibly provide it's
> own hacks for what to do with -Os.
>
> Is the patch okay to install as-is, or did you want the checks for
> constant FP_* arguments?

I'd like to have the check for constant FP_* arguments (and the docs
adjusted).  The patch is ok with that change.

Thanks,
Richard.