Open Eisenwave opened 3 months ago
the arm64 also has such issue https://godbolt.org/z/fsfYeeshx
@llvm/issue-subscribers-backend-x86
Author: Jan Schultke (Eisenwave)
@llvm/issue-subscribers-backend-aarch64
Author: Jan Schultke (Eisenwave)
As far as I know, fmod
can set errno
on a domain error which means that transforming fmod
to frem is illegal. -ffast-math
suppresses errno
which means we can use the frem
instruction. (However this is confusing since I'd assume the presence of the builtin would imply ignoring errno
as well.)
The frem
instruction is then lowered directly by the X86 backend, which doesn't include any of the tail call optimizations we get from the LLVM-IR passes. See the pipeline in https://godbolt.org/z/vK6EEqc4E. Likely someone just needs to improve the lowering.
CC @arsenm
We currently have 2 paths for emitting libcalls, for some reason. TargetLibraryInfo::makeLibCall looks like it's not attempting to make tail calls when the call is routed through FREM. The Legalizer in SelectionDAGLegalize::ExpandLibCall does
https://godbolt.org/z/83cTWb7T6
With
-O3
, this emitsWith
-O3 -ffast-math
:Is this intentional? Seems like a missed optimization. I suspect the problem is that the codegen for the
frem
instruction never results in a tail-call. The irony is that the codegen is justcall fmodf
, so the "naive" library call tofmodf
is better than the one resulting fromfrem
codegen.The same code with
__builtin_remainderf
always tail-calls: