| Message ID | CAFULd4bFG1vg7KyukZwfSup83pNVVKhER-OC=ZgKUepJje6_3g@mail.gmail.com |
|---|---|
| State | New |
| Headers | show |
On Fri, 10 Jun 2016, Uros Bizjak wrote: > Joseph, does it look OK to you? Richi, I hope I got tree stuff > implemented correctly. It's plausible, but really needs testcases (which could examine the bit-patterns of __float128 objects initialized using these built-in functions, to make sure those are as expected).
On Fri, Jun 10, 2016 at 11:55 PM, Joseph Myers <joseph@codesourcery.com> wrote: > On Fri, 10 Jun 2016, Uros Bizjak wrote: > >> Joseph, does it look OK to you? Richi, I hope I got tree stuff >> implemented correctly. > > It's plausible, but really needs testcases (which could examine the > bit-patterns of __float128 objects initialized using these built-in > functions, to make sure those are as expected). Yes, I plan to add these testcases as a follow-up (including __builtin_infq) for all __float128 targets. Uros.
On Fri, 10 Jun 2016, Uros Bizjak wrote: > Hello! > > Attached patch implements __builtin_nanq and __builtin_nansq > __float128 functions. > > 2016-06-10 Uros Bizjak <ubizjak@gmail.com> > > PR target/71241 > * config/i386/i386.i386-builtin-types.def (CONST_STRING): > New primitive type. > (FLOAT128_FTYPE_CONST_STRING): New function type. > * config/i386/i386.c (enum ix86_builtins) [IX86_BUILTIN_NANQ]: New. > [IX86_BUILTIN_NANSQ]: Ditto. > (ix86_fold_builtin): Handle IX86_BUILTIN_NANQ and IX86_BUILTIN_NANSQ. > (ix86_init_builtin_types) Declare const_string_type_node. > Add __builtin_nanq and __builtin_nansq builtin functions. > (ix86_expand_builtin): Handle IX86_BUILTIN_NANQ and IX86_BUILTIN_NANSQ. > * doc/extend.texi (x86 Built-in Functions): Document > __builtin_nanq and __builtin_nansq. > > Patch was bootstrapped and regression tested on x86_64-linux-gnu {,-m32}. > > Joseph, does it look OK to you? Richi, I hope I got tree stuff > implemented correctly. Hmm, as we already have BUILT_IN_NAN[S] why not add NAN128 and NANS128 variants in the middle-end as we already have NAND128 (for decimal float 128)? I don't see why we need target specific builtins for this given you simply use middle-end functionality to construct the result. Richard.
On Mon, Jun 13, 2016 at 10:01 AM, Richard Biener <rguenther@suse.de> wrote: > On Fri, 10 Jun 2016, Uros Bizjak wrote: > >> Hello! >> >> Attached patch implements __builtin_nanq and __builtin_nansq >> __float128 functions. >> >> 2016-06-10 Uros Bizjak <ubizjak@gmail.com> >> >> PR target/71241 >> * config/i386/i386.i386-builtin-types.def (CONST_STRING): >> New primitive type. >> (FLOAT128_FTYPE_CONST_STRING): New function type. >> * config/i386/i386.c (enum ix86_builtins) [IX86_BUILTIN_NANQ]: New. >> [IX86_BUILTIN_NANSQ]: Ditto. >> (ix86_fold_builtin): Handle IX86_BUILTIN_NANQ and IX86_BUILTIN_NANSQ. >> (ix86_init_builtin_types) Declare const_string_type_node. >> Add __builtin_nanq and __builtin_nansq builtin functions. >> (ix86_expand_builtin): Handle IX86_BUILTIN_NANQ and IX86_BUILTIN_NANSQ. >> * doc/extend.texi (x86 Built-in Functions): Document >> __builtin_nanq and __builtin_nansq. >> >> Patch was bootstrapped and regression tested on x86_64-linux-gnu {,-m32}. >> >> Joseph, does it look OK to you? Richi, I hope I got tree stuff >> implemented correctly. > > Hmm, as we already have BUILT_IN_NAN[S] why not add NAN128 and NANS128 > variants in the middle-end as we already have NAND128 (for decimal float > 128)? > > I don't see why we need target specific builtins for this given you > simply use middle-end functionality to construct the result. This goes together with __builtin_infq. These functions are not standardized yet, so we have to resort to target-dependent semi-hacks. Once _f128 functions are standardized, this functionality can be moved to the middle end as a generic expander. Uros.
On Mon, 13 Jun 2016, Richard Biener wrote: > Hmm, as we already have BUILT_IN_NAN[S] why not add NAN128 and NANS128 > variants in the middle-end as we already have NAND128 (for decimal float > 128)? The middle-end does not know anything about the target-specific __float128 type. Now, I'm looking at what would be involved in supporting the TS 18661-3 type names (_Float128 etc. - keywords, so that e.g. _Complex _Float128 works; cf bug 32187), constant suffixes (f128 etc.) and float.h macros (FLT128_* etc.) in GCC. Some questions arise for the design of both basic support and built-in functions: * The set of possible _Float* types is infinite: _Float32x, _Float64x, _Float128x, _FloatN where N is 16, 32, 64 or >= 128 and a multiple of 32. I'm not aware of any systems that actually implement a type that could be _FloatN for N > 128 (or _Float128x). Given that, should we hardcode a particular set of tree nodes for seven _FloatNx and _FloatN types, or build something more extensible like the __intN support (where there *are* processors with various different type sizes)? In any case, not all the types would exist on all targets (_Float128x not existing on any targets), and existence of a type would sometimes depend on command-line options. * We don't know how C++ might handle such types, but the example of decimal floating point (where C++ uses class types) suggests substantially different from C. That would imply that the syntax that could access such types - the keywords, constant suffixes and built-in functions - should not be enabled for C++. Except that given you have __float128 in C++, it might be desirable for e.g. __builtin_nanf128 to work for C++ as well. (Presume that __float128 would become a built-in typedef for _Float128, not a distinct type. All _FloatN and _FloatNx are however distinct from each other and from float, double, long double, even if they have the same ABI.) * Optimal support would involve built-in functions for the new types. You could add a minimal set like those that exist for __float128 (that would be 42 functions - six for each of seven types - if you hardcode the set of types). But optimally all the built-in floating-point functions, real and complex, would be enabled for the new types (or at least all those for standard C functions would be; in the glibc community we've discussed how a few functions not in standard C should be considered obsolescent and so not get versions for new types). However, with the present built-in infrastructure, that's a lot of new built-in functions that get added to an enum (and we've had issues with huge enums) and initialized at runtime, and not all cases using such built-in functions use CASE_FLT_FN. Then you have optimizations in match.pd that only operate with float / double / long double, and more in convert.c and probably elsewhere with similar logic not generic to having lots of floating-point types.
Index: config/i386/i386-builtin-types.def =================================================================== --- config/i386/i386-builtin-types.def (revision 237270) +++ config/i386/i386-builtin-types.def (working copy) @@ -73,6 +73,7 @@ DEF_PRIMITIVE_TYPE (FLOAT, float_type_node) DEF_PRIMITIVE_TYPE (DOUBLE, double_type_node) DEF_PRIMITIVE_TYPE (FLOAT80, float80_type_node) DEF_PRIMITIVE_TYPE (FLOAT128, float128_type_node) +DEF_PRIMITIVE_TYPE (CONST_STRING, const_string_type_node) # MMX vectors DEF_VECTOR_TYPE (V2SF, FLOAT) @@ -191,6 +192,7 @@ DEF_FUNCTION_TYPE (PVOID) DEF_FUNCTION_TYPE (FLOAT, FLOAT) DEF_FUNCTION_TYPE (FLOAT128, FLOAT128) +DEF_FUNCTION_TYPE (FLOAT128, CONST_STRING) DEF_FUNCTION_TYPE (INT, INT) DEF_FUNCTION_TYPE (INT, V16QI) DEF_FUNCTION_TYPE (INT, V2DF) Index: config/i386/i386.c =================================================================== --- config/i386/i386.c (revision 237270) +++ config/i386/i386.c (working copy) @@ -32718,6 +32718,8 @@ enum ix86_builtins /* TFmode support builtins. */ IX86_BUILTIN_INFQ, IX86_BUILTIN_HUGE_VALQ, + IX86_BUILTIN_NANQ, + IX86_BUILTIN_NANSQ, IX86_BUILTIN_FABSQ, IX86_BUILTIN_COPYSIGNQ, @@ -38105,11 +38107,28 @@ ix86_fold_builtin (tree fndecl, int n_args, { enum ix86_builtins fn_code = (enum ix86_builtins) DECL_FUNCTION_CODE (fndecl); - if (fn_code == IX86_BUILTIN_CPU_IS - || fn_code == IX86_BUILTIN_CPU_SUPPORTS) + switch (fn_code) { + case IX86_BUILTIN_CPU_IS: + case IX86_BUILTIN_CPU_SUPPORTS: gcc_assert (n_args == 1); - return fold_builtin_cpu (fndecl, args); + return fold_builtin_cpu (fndecl, args); + + case IX86_BUILTIN_NANQ: + case IX86_BUILTIN_NANSQ: + { + tree type = TREE_TYPE (TREE_TYPE (fndecl)); + const char *str = c_getstr (*args); + int quiet = fn_code == IX86_BUILTIN_NANQ; + REAL_VALUE_TYPE real; + + if (str && real_nan (&real, str, quiet, TYPE_MODE (type))) + return build_real (type, real); + return NULL_TREE; + } + + default: + break; } } @@ -38210,7 +38229,7 @@ ix86_init_builtins_va_builtins_abi (void) static void ix86_init_builtin_types (void) { - tree float128_type_node, float80_type_node; + tree float128_type_node, float80_type_node, const_string_type_node; /* The __float80 type. */ float80_type_node = long_double_type_node; @@ -38230,6 +38249,10 @@ ix86_init_builtin_types (void) layout_type (float128_type_node); lang_hooks.types.register_builtin_type (float128_type_node, "__float128"); + const_string_type_node + = build_pointer_type (build_qualified_type + (char_type_node, TYPE_QUAL_CONST)); + /* This macro is built by i386-builtin-types.awk. */ DEFINE_BUILTIN_PRIMITIVE_TYPES; } @@ -38250,6 +38273,18 @@ ix86_init_builtins (void) def_builtin_const (0, "__builtin_huge_valq", FLOAT128_FTYPE_VOID, IX86_BUILTIN_HUGE_VALQ); + t = ix86_get_builtin_func_type (FLOAT128_FTYPE_CONST_STRING); + t = add_builtin_function ("__builtin_nanq", t, IX86_BUILTIN_NANQ, + BUILT_IN_MD, "nanq", NULL_TREE); + TREE_READONLY (t) = 1; + ix86_builtins[(int) IX86_BUILTIN_NANQ] = t; + + t = ix86_get_builtin_func_type (FLOAT128_FTYPE_CONST_STRING); + t = add_builtin_function ("__builtin_nansq", t, IX86_BUILTIN_NANSQ, + BUILT_IN_MD, "nansq", NULL_TREE); + TREE_READONLY (t) = 1; + ix86_builtins[(int) IX86_BUILTIN_NANSQ] = t; + /* We will expand them to normal call if SSE isn't available since they are used by libgcc. */ t = ix86_get_builtin_func_type (FLOAT128_FTYPE_FLOAT128); @@ -41463,6 +41498,10 @@ ix86_expand_builtin (tree exp, rtx target, rtx sub return target; } + case IX86_BUILTIN_NANQ: + case IX86_BUILTIN_NANSQ: + return expand_call (exp, target, ignore); + case IX86_BUILTIN_RDPMC: case IX86_BUILTIN_RDTSC: case IX86_BUILTIN_RDTSCP: Index: doc/extend.texi =================================================================== --- doc/extend.texi (revision 237270) +++ doc/extend.texi (working copy) @@ -18476,6 +18476,14 @@ Similar to @code{__builtin_inf}, except the return @item __float128 __builtin_huge_valq (void) Similar to @code{__builtin_huge_val}, except the return type is @code{__float128}. @findex __builtin_huge_valq + +@item __float128 __builtin_nanq (void) +Similar to @code{__builtin_nan}, except the return type is @code{__float128}. +@findex __builtin_nanq + +@item __float128 __builtin_nansq (void) +Similar to @code{__builtin_nans}, except the return type is @code{__float128}. +@findex __builtin_nansq @end table The following built-in functions are always available and can be used to
Hello! Attached patch implements __builtin_nanq and __builtin_nansq __float128 functions. 2016-06-10 Uros Bizjak <ubizjak@gmail.com> PR target/71241 * config/i386/i386.i386-builtin-types.def (CONST_STRING): New primitive type. (FLOAT128_FTYPE_CONST_STRING): New function type. * config/i386/i386.c (enum ix86_builtins) [IX86_BUILTIN_NANQ]: New. [IX86_BUILTIN_NANSQ]: Ditto. (ix86_fold_builtin): Handle IX86_BUILTIN_NANQ and IX86_BUILTIN_NANSQ. (ix86_init_builtin_types) Declare const_string_type_node. Add __builtin_nanq and __builtin_nansq builtin functions. (ix86_expand_builtin): Handle IX86_BUILTIN_NANQ and IX86_BUILTIN_NANSQ. * doc/extend.texi (x86 Built-in Functions): Document __builtin_nanq and __builtin_nansq. Patch was bootstrapped and regression tested on x86_64-linux-gnu {,-m32}. Joseph, does it look OK to you? Richi, I hope I got tree stuff implemented correctly. Uros.