[llvm] SimplifyLibCalls: Don't require ldexp to emit intrinsic in exp2 combine (PR #92707)

[Matt Arsenault via llvm-commits]

arsenm wrote:

> If we reserve the right to call ldexp anywhere, under any set of flags, how is anyone supposed to implement a C library?

This is already not possible, but is a problem to solve in codegen for when the intrinsic implementation is emitted. We need some mechanism to disable RuntimeLibcalls when building a libc. 

IMO it was wrong to provide any math intrinsics to expose the usage of math functions. These intrinsics should be providing the target implementation of the libm functions, not the other way around. If we can't codegen the intrinsic without the libcall, we probably shouldn't have the intrinsic. 

Treating the intrinsics as aliases to the library calls isn't really useful. We have to maintain parallel optimization paths for the intrinsic and call anyway, then have a lot of machinery to turn the calls into intrinsics, and then the intrinsics back into libcalls.

Alternative to this, I could fix it to preserve libcall->libcall behavior and intrinsic->intrinsic behavior. The main problem I'm trying to solve is gating intrinsic->intrinsic gated on the libcall availability 


>  I guess this particular combine is unlikely to cause issues, but if you're planning to rip out all checks for whether a functions exists, it seems like something we need to address.

For today, I just want to fix ldexp. We need to come up with a RuntimeLibcalls solution eventually (e.g. see the inline asm in llvm-libc to use fma instead of calling the fma intrinsic)

> Long-term, we really need a better approach for managing the codesize explosion that comes from expanding everything inline.

We could also undo this optimization in codegen if ldexp isn't available (which in practice just means windows) and call pow 


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