[PATCH] D122610: [SDAG] avoid libcalls to fmin/fmax for soft-float targets

Mon Mar 28 12:59:15 PDT 2022

efriedma accepted this revision.
efriedma added a comment.
This revision is now accepted and ready to land.

LGTM.  (As a followup, we could consider querying TargetLibraryInfo to see if fmax is available, instead of assuming it isn't.)

----

The general question could probably use some thought... currently, the compiler is very constrained in terms of helper routines.  We're basically constrained to calling memcpy/memset/memmove, plus whatever routines are exposed by libgcc, plus whatever TargetLibraryInfo tells us is available.  This is pretty limiting: we're currently forced to inline routines we don't really want to inline due to codesize, like multiply-with-overflow, or minnum.  Or we have to add weird checks along the lines of D70852 <https://reviews.llvm.org/D70852>.  (This is made worse by the fact that SelectionDAG lowering can't really generate control flow.)  We basically can't add new routines to compiler-rt builtins because a large fraction of users end up linking with libgcc.

It might be worth considering if we could come up with a mechanism to embed the routines we need into each object file; sort of like compiler-rt builtins, but you wouldn't have to actually link against compiler-rt.  So each object file that needs a helper contains a hidden weak symbol, e.g. __llvm_mul_with_overflow_32_v1, and the linker picks one.  Sort of wasteful in terms of disk space in object files and static libraries, but it would allow us to add helpers while staying compatible with build systems we don't control.

Just food for thought; I don't have a complete proposal at this point.

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D122610/new/

https://reviews.llvm.org/D122610