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

Isaac Richter via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Mon Mar 28 13:32:28 PDT 2022


irichter added a comment.

The tests look good; I still need to see how it handles the usecase that originally prompted my bug report.

In D122610#3412307 <https://reviews.llvm.org/D122610#3412307>, @efriedma wrote:

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

It might be nice to have a switch, possibly controlled by one of the `-Os`, that would prefer the `fmax` call.

> 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.

Regarding disk space, while it's worse than using a compiler-rt builtin, it's not generally worse than just embedding the code at every point that needs it, since it only appears once per file. Moreover, if this is done by adding intrinsics, the additional disk space would only be realized after machine code generation, and would not be an issue at all with LTO.

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

I like this idea, and not just for this particular issue, but more generally for things that are tightly integrated with the compiler, but require runtime support (e.g.: sanitizers).


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

https://reviews.llvm.org/D122610



More information about the llvm-commits mailing list