Incorporating tlfloat as a submodule

[shibatch]

As described in #544, I am now considering to incorporate tlfloat as a submodule of sleef.
The primary reason for incorporating tlfloat is to provide an alternative tester to tester1, as described in #544.
I'll post a separate issue with more details, but the goal is to provide a testing equivalent to tester1 for those environments where mpfr cannot be used.
This is not intended to completely replace the current tester1 with the new tester with tlfloat. The new tester will be only an alternative.
When building sleef, you will be able to specify whether or not to use the tlfloat functionality by using a cmake option.

In addition to the new tester, tlfloat makes it easier for sleef to handle data types that are not directly supported by each architecture (e.g. float16 and float128).
Some functions of sleef (such as printf) have no room for vectorization, and it is more appropriate to implement them in tlfloat than in sleef.
In the future, implementation of functions such as printf will be removed from sleef and the equivalent functions in tlfloat will be called.
This means that when I add the new tester, the users will be allowed to choose whether or not to use the tlfloat feature, but in the future I will need to tightly couple the tlfloat as part of the sleef functionality.

For the above reasons, I believe it is appropriate to incorporate tlfloat as a submodule of sleef.
Concerns regarding incorporating tlfloat as a sleef submodule include the following.

• tlfloat is not a widely used library at this point, so it would be appropriate to include it as a submodule
  • Is it actually better to use find_library etc. like other libraries?
  • Can other projects using sleef be compatible?
• tlfloat needs to be built with C++20.
  • Since the current sleef can be built only with a C compiler, this could create confusion.
  • C++20 is a new standard, so other projects using older compilers may have difficulty
  • clang-16 or earlier cannot build tlfloat due to compiler bugs

In addition, tlfloat incorporates a new code of conduct. This code of conduct is still being edited in parallel with the development of tlfloat.
I would like to adopt the same code of conduct in sleef in the future, but only after I have received positive feedback from sleef users and other people, and have confirmed that there is sufficient support for the new code of conduct.

For more information, see https://github.com/shibatch/nofreelunch, and please write to https://github.com/shibatch/nofreelunch/discussions with your comments on this code of conduct.

[blapie]

Thanks for giving an overview of the plan. I have many questions, feel free to give short answers and address in more details later or in new issue.

1. When you create the separate issue, could you make sure to use the new Feature Request template, and state what problems this new feature/dependency solves and how it does solve them? What limits does this solution have (you mentioned a few here)? what alternatives are there (maybe)?

2. In what environment is MPFR not usable/available? What OS? Architecture?

3. One of the problems we were experiencing with the testers is actually the posix dependency (wait.h), which for instance prevents testing on Windows (native, as in not Cygwin). Can this dependency also be removed from tester1 and the new tester?

A few extra questions on maintainability:

4. Why would we still require tester1? Just asking because I'm concerned about maintainers having to look after tester1 and a new dependency (tlfloat). Can we get rid of at least a substantial part of tester1? Do you want to keep it because some users might not be able to satisfy the dependency on C++20 and would need an alternative tester?

5. Since it is probably a substantial change to make to SLEEF tester as well as source code (if I understand well), could we have a proof of concept showing how it affects each part of the code individually, e.g. printf, tester, ... This question is just anticipating review.

6. Would you say this will generally improve the quality of the code base? Or does it add more complexity?

[shibatch]

Thank you for your comment.

1. I understand. I will do that next time.

2. My understanding is that tester1 is currently not executed on Windows? It is possible to use tester1 compiled with Cygwin to test binaries compiled with MSVC, but this is pretty tricky.

3. My current plan is not to touch tester1. Or simply add an option to disable tester1 as a cmake option. wait.h will not be used in the new tester.

4. Why would you rather remove tester1? If you don't need it, I guess you can just disable it upon a build. It would be good to do the testing with either tester1 or the new tester.

5. Adding a new tester is not such a major change. It simply adds tester4.

6. This change is not a major change. However, it may lead to major changes to the code base in the future. We can discuss that again at that time.