JIT: explicitly handle __extendhfsf2 and friends

[vtjnash]

A partial fix to #44829, but perhaps we will still have ABI problems with the sysimg (which may not link directly enough on linux in many cases)

@nalimilan @vchuravy I don't know how to make the linux linker work any better than this. The COFF and MACHO linkers would support two-level namespaces which would solve it, but the linux ELF implementations likely have problems with this still.

[vtjnash]

Suggested change

	extern uint16_t __gnu_f2h_ieee(float param);
	extern double __gnu_f2h_ieee(uint16_t param);

(not that it matters here, since we just need the declared prototype)

[vchuravy]

Another idea, adjust the TLI to have different names for these intrinsics? There are two reasons for trying to supply our own. 1. Some platforms were missing these, 2. We want our rounding semantics

[vtjnash]

Ah, are we able to do that? Do you know how we can change these TLI names?

[vchuravy]

When in question do what Clang does? https://github.com/llvm/llvm-project/blob/26b0ecb8985b7e76a5ca0965d3d464611eda14f0/clang/lib/CodeGen/BackendUtil.cpp#L246-L278

and since we then have a TLII we should be able to use https://llvm.org/doxygen/classllvm_1_1TargetLibraryInfoImpl.html#a27e3c60feefa1643f8c8dafe485a1e1f

[vtjnash]

I thought the TargetLibraryInfoImpl was private to the TargetMachine so that passes couldn't access or change it

[vchuravy]

That is true passes can't access it directly, but when you create your TM you can pass it a TLII and you can change it beforehand as Clang does in the link above

[alexfanqi]

Could you also add __truncsfhf2, which is an equivalent version of __gnu_f2h_ieee. When working on the riscv port, I found llvm and gcc will emit a call to __truncsfhf2 on riscv instead of __gnu_f2h_ieee.