Re: IA64 HP-UX __builtin_finite patch (and questions about __builtin_)

["Roger Sayle" <roger at eyesopen dot com>]

Hi Steve,

On Thu, January 11, 2007 3:32 pm, Steve Ellcey wrote:
>> The general rule is that __builtin_foo shouldn't be used on systems
>> that don't provide a foo [which the exceptions that prove the rule
>> being GCC builtins, known intrinsics, etc...]  So the current situation
>> is that the testcase pr28796-2.c should be restricted to platforms that
>> support finite.  Better yet it should be split into independent tests,
>> such that the isunordered and isnan continue to be tested on ia64-hpux.
>
> I thought about this and I wonder if a bit flag should be added to the
> builtin table to specify whether a particular builtin was supported or
> not.  It could be set to true by default and then specific targets could
> set it to false for builtins they don't support.

Of course, we already have that bit and it controls whether we intercept
calls to "foo" and process them as we would calls to __builtin_foo.  The
__builtin_foo forms are provided for the convenience of GCC's runtime
libraries, system headers and GCC-aware source codes.  The trouble is that
our own dejagnu testsuite uses the __builtin_foo form to double check that
the optimizers are doing there job without relying on the system headers.

As you point out, in normal usage "finite" and "isnan" are actually
macros, and occassionally on glibc targets those macros expansions may
contain references to __builtin_nan.  Much like __builtin_setjmp and
__builtin_longjmp, these are helper functions whose semantics don't
necessarily reflect those of public "isnan", "setjmp" or "longjmp".

>> Given that, patches such as the one that you propose to map the user
>> identifier to the system provided one are the appropriate/better fix.
>
> I may check it in as a short term fixus.

I agree that's sensible.  I just wondered if you were willing to attempt
an optabs based solution, or if Uros or Richard G owed you any favours :-)

>> Longer term, however, for this particular case, I think ultimately
>> we should have suitable optabs, and on IA-64 expand isnan, isinf,
>> and finite (and maybe even fpclassify) as inline intrinsics.  These
>> could then take advantage of the IA-64's special "fclass" instruction,
>> which is especially suited to implementing these functions.
>>
> I agree that this is the best long term direction, but the definition of
> these C99 macros as macros (instead of functions) seems to make it more
> difficult.  I don't want to go through the work of having
> __builtin_finite (or __builtin_isfinite) get expanded to inline code and
> then have a regular C99 isfinite macro call not get expanded into inline
> code.

Indeed.  The goal would be for the middle-end to recognize the idioms used
in <math.h>'s macro expansion.  Fortunately, this is the case for glibc's
math.h, which the middle-end can reduce to a possible finitedfsi2
expander.
Other targets need suitably clever implementations in fold, or to be
fixincluded to produce something recognizable.

Roger
--