[builtins] Convert more int to fp functions to use common implementation

[asb]

Builds on #66903, converting the rest of the low-hanging fruit to use the common implementation.

I was holding off posting more of the patch series as it's (sadly) rather awkward on GitHub. But I'll post this next patch in the hope it better demonstrates the direction.

[asb]

Ping for review. I've rebased now that #66903 has landed and additionally can demonstrate equivalence using Alive2 (caveat below):

• floatdisf
  • https://alive2.llvm.org/ce/z/mcAyPM
• floattidf
  • https://alive2.llvm.org/ce/z/rM7kPz
• floattisf
  • https://alive2.llvm.org/ce/z/HJp4jp
• floattitf
  • https://alive2.llvm.org/ce/z/6pGHuH
• floatundisf
  • https://alive2.llvm.org/ce/z/4uTm_H
• floatuntidf
  • https://alive2.llvm.org/ce/z/SCWV7J
• floatuntisf
  • https://alive2.llvm.org/ce/z/acoFF5
• floatuntitf
  • https://alive2.llvm.org/ce/z/t3QaLr

The caveat is that alive2 won't show equivalence for the functions that take i128 as an input where __clzti2 is called (there is no __builtin_clz variant in Clang for i128, so no way to generate llvm.ctlz.i128 calls). It doesn't understand it's semantics and seemingly the conservative analysis it does results in slightly different cases where poison is introduced for the two functions. However, massaging the output to replace that call with one to llvm.ctlz.i128 does show equivalence. I did encounter a gotcha whereby incorrectly doing this replacement (e.g. getting the signature wrong) would indicate llvm.ctlz.i128 = constant ? bytes, align 8 in Alive's output and it confidently claimed equivalence when e.g. changing one of the call args to a constant. The linked comparisons avoid this issue though.

[alexander-shaposhnikov]

The changes look good to me, thank you.
One thing that I did for testing (that gave me a bit more confidence) was verifying that the conversions produce exactly the same results as before for all possible values of small types (up to float). E.g. one can save all pairs (src_value, dst_value) into old.txt and new.txt and compare them.

[arichardson]

This seems to have broken __floatuntitf for x86_64 (noticed after rebasing #68132 on top of this).

[arichardson]

__floattitf(1) is returning 0.0 instead of 1.0 with this change.

[arichardson]

I found the underlying issue which is not a regression from this chage, just a failed conflict resultion on my side. Apologies for the noise.

[rorth]

This patch badly broke the Solaris/sparcv9 buildbot which has 128-bit long double, but no *int128_t.

[arichardson]

I think one way to fix the solaris error would be to lift
#if defined(CRT_HAS_TF_MODE) before this include since it also requires __int128.

[arichardson]

Or adding a #ifdef CRT_HAS_128BIT

[rorth]

This works indeed. floattitf.c needs the same patch. It's unfortunate, however, that int_to_fp.hisn't more robust, unconditionally using types whose existance isn't guaranteed everywhere.