[llvm] [SelectionDAG] Handle roundeven libcall in visitCall (PR #170690)

[Matt Arsenault via llvm-commits]

arsenm wrote:

> Is there any plan for fixing this? I saw you opened a bunch of libcall-related PRs, and I'm wondering if those are working towards improving the situation.

It won't help with this particular issue, but what I'm working towards is supporting emitting libcalls that to functions defined in the module. That will permit handling most intrinsics in the GPU case which fail today.

> Why is it that transforming a libcall into an intrinsic could be incorrect, though? 

It's not incorrect per se, as it is there's a QoI issue where the intrinsic may fail depending on the target. Trivial cases like `roundeven -> llvm.roundeven` probably will workout (provided RuntimeLibcallsInfo and TargetLibraryInfo are in agreement). Cases where the legalizer only has the option of calling the host libcall are a liability.

>  the worst that can happen is that the intrinsic is lowered back into the same libcall. 

This assumes you can emit a libcall, and it's not always as simple as a 1:1 mapping. The transforms that have run into issues are where a libcall is transformed into an intrinsic for a different operation, which has worse support on the target. e.g. `powf->llvm.ldexp.f32`. On windows there is no `ldexpf` so it becomes a special case that requires additional backend consideration (this case works, but didn't always). There are a number of legalization holes of that shape. The other issue is backend introduced function calls are hidden from the linker, so if you are doing LTO with libm functions defined in the same program, they may have been dropped from the link if they were originally unused. Currently RuntimeLibcallsInfo is used in LTO to conservatively retain functions which may be called, but that does not yet accurately track all functions that the compiler could emit.

I really don't like all of the intrinsics we have that exist solely to call into a host library functions. If the compiler is not providing the functionality (or at least compiler-rt), we probably shouldn't have an intrinsic for it.

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