Extended precision floating point support

[chuckatkins]

This is to track the issues surrounding support for extended precision float, i.e. long double. Some things to consider:

1. The multitude of precision and byte representations to support.
2. Cross-language support (Fortran REAL(16) may or may not be supported at all and if it is, may not be the same as the corresponding C / C++ long double)
3. Padding issues on non-dense representations (i.e. 80-bit long double taking up 128 bits of space)
4. Read support for formats not supported by the current architecture.

[chuckatkins]

See discussions in #1907 and #1921 for

[KyleFromKitware]

I am currently playing around with ways to detect the bit representation of long double using try_compile(). I think we may actually be able to get that into CMake upstream (and backport it here.)

[chuckatkins]

@ax3l @germasch

[germasch]

I can think of a number of questions that should be answered:

• Which extended floating points do you want to support in the API?
• How do you handle padding within BP3/4 buffers?
• How to handle backwards compatibility?

So I think the types that adios2 should support on any given system are:

• long double (always exists, though it could just be the same as double) and
• maybe: __float128. (may not exist). The other question, though, is whether there is demand to support in the first place.

I guess it's a choice, but supporting a floating point type which isn't natively supported by the compiler / platform would be quite a pain and I don't see the usefulness -- who would want to read data which they then can't process?

So on the external API side, you'd want to add long double and maybe __float128. Internally, you want to support those same types, too, though the internal types need to unique, otherwise you'll get duplicate template instantiations. In particular, one needs to be careful when std::is_same<long double, double>, which I believe is the case on MSVC. Obviously that's easy to test in C++, but I think it actually needs to be known at the preprocessor level because of the ubiquitous use of the FOREACH macros.

I don't see that the binary representation that long double to corresponds to necessarily needs to be known at compile time (other than != float64). It'd be easy to determine it at runtime, and primarily it should only be needed to determine which datatype to encode in the BP3/4/whatever file format. One would need to know about the existence of __float128 at compile time if that's to be supported.

The other question is what to do with the padding. Currently, adios2 essentially does memcpys of the buffer into BP buffers, which would copy the padding as well. As has already turned up here, that can lead to spurious warnings about uninitialized memory, and potentially even leaking of sensitive information. The other disadvantage would be that it wouldn't be possible to read long double written on 32-bit Linux back on 64-bit Linux or vice versa, even though both are 80-bit float, but with different padding. (Though I doubt there's a lot of use of adios2 on 32-bit Linux.)

The alternative would be to rearrange the data to drop the padding before putting things into the BP buffer, and adding it back when reading. The disadvantage to that is that it requires, essentially, a memory copy, and eliminates the possibility of doing anything zero-copy. While touching the entire buffer to eliminate padding is not exactly cheap, I suppose it should be quite a bit cheaper than sending all the useless padding data to disk or over the network, as that bandwidth is much less than memory bandwidth.

Finally, there's a question about what to do when reading existing BP3/4 files, which don't encode the details of the actual extended floating point that was written. I suppose if one reads a file on a given architecture, one would want to assume that the long double representation is the same as the one currently reading it. One might at least want to be careful to avoid buffer overflows, ie., a sanity check of whether sizeof(long double) == sizeof(type in file)`. I'm not sure that it's possible to recover the size of the type that was written from BP3/4, but it may be.

The other aspect to this is that going forward one should encode, say, "R80_96" or "R80_128" or whatever as distinct types into the BP3 file, which means that new type ids will need to be introduced, and old readers won't know how to handle them.