[compiler-rt] [builtins][AArch32] Fix __gnu_* functions (PR #137638)

[Peter Smith via llvm-commits]

smithp35 wrote:

I think we may need a bit more evidence collected to make sure we're doing the right thing across all platforms. 

When I look at the ARM libgcc prototypes https://github.com/gcc-mirror/gcc/blob/master/libgcc/config/arm/fp16.c#L56 
```
unsigned short __gnu_f2h_ieee (unsigned int a);
unsigned int __gnu_h2f_ieee (unsigned short a);
unsigned short __gnu_f2h_alternative (unsigned int x);
unsigned int __gnu_h2f_alternative (unsigned short a);
unsigned short __gnu_d2h_ieee (unsigned long long a);
unsigned short __gnu_d2h_alternative (unsigned long long x);
```
These have a core register interface, and I'm not sure your proposed change reflects that for the source parameter. As it looks like src_t may be float.

So if an Arm GCC compiled object calls one of these functions I think it will still be wrong.

Looking at LLVM ARMISelLowering.cpp these functions may be called by  MachO
```
  } else if (!Subtarget->isTargetMachO()) {
    setLibcallName(RTLIB::FPROUND_F32_F16, "__gnu_f2h_ieee");
    setLibcallName(RTLIB::FPEXT_F16_F32, "__gnu_h2f_ieee");
  }
```
It is highly likely that the interface is correct for MachO but not for calls via libgcc.

Can you do some research to make sure:
* What targets in GCC may call `__gnu_h2f` and friends and what is their expected interface?
* What targets in LLVM may call `__gnu_h2f` and friends and what is their expected interface?
* Can you make sure that the change to compiler-rt works for all of these targets. For example we may need to compile differently for MachO (Darwin) than for ELF.


https://github.com/llvm/llvm-project/pull/137638