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. -- Joseph S. Myers jos...@codesourcery.com
