uweigand wrote: To clarify about soft-float - we do support `-msoft-float` as a compiler option, but there is no actual soft-float library provided anywhere; never has been. The compiler option is still useful in particular for the case of the Linux kernel: kernel code does not actually have any floating-point operations or even data types at the C source level, but the compiler would normally still be free to use floating-point instruction and registers (or even vector instruction and registers). This would conflict with the fact that the kernel does not save / restore floating-point or vector registers at system call (or interrupt) entry or exit. Therefore, the kernel uses `-msoft-float` to indicate to the compiler to never touch any floating-point or vector register in generated code. Because the kernel does not use floating-point operations at the source level, the compiler can achieve this goal without ever emitting any call to a soft-float library routine.
There is no user-space code that uses `-msoft-float` on SystemZ, and that wouldn't really make sense anyway - every SystemZ hardware in existence has full support for floating-point operations natively (IEEE-32, -64, and -128). To bring this back to the original topic of floating-point support in the compiler runtime libraries: there are a small number of such routines today, but those are not intended for use with soft-float (they do expect the normal hard-float ABI, i.e. passing floating-point values in floating-point registers), but rather implement a few corner-case operations (like int128 <-> float conversion) where we actually do not have hardware instructions. Any new f16-related compiler runtime library routine would fall into this category, *not* the soft-float category. https://github.com/llvm/llvm-project/pull/109164 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
