[llvm-dev] InstCombine makes assumptions on math functions
Alexandre Isoard via llvm-dev
llvm-dev at lists.llvm.org
Thu Feb 25 14:06:00 PST 2021
Hello,
I see InstCombine makes assumptions on functions named with C math function
names.
For example it will optimize the following code:
target datalayout = "e-m:e-i64:64-f80:128-n8:16:32:64-S128"
target triple = "x86_64-unknown-linux-gnu"
define dso_local double @fabs(double %x) {
%res = fmul double %x, %x
ret double %res
}
define dso_local float @_Z3foof(float %x) {
entry:
%conv = fpext float %x to double
%0 = call double @fabs(double %conv)
%conv1 = fptrunc double %0 to float
ret float %conv1
}
Into the following:
target datalayout = "e-m:e-i64:64-f80:128-n8:16:32:64-S128"
target triple = "x86_64-unknown-linux-gnu"
define dso_local float @_Z3foof(float %x) {
entry:
%conv1 = call float @llvm.fabs.f32(float %x)
ret float %conv1
}
; Function Attrs: nounwind readnone speculatable
declare double @llvm.fabs.f64(double) #0
; Function Attrs: nounwind readnone speculatable
declare float @llvm.fabs.f32(float) #0
attributes #0 = { nounwind readnone speculatable }
It seems to have assumed my @fabs function was the @llvm.fabs.f64 intrinsic.
Is that correct behavior?
--
*Alexandre Isoard*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20210225/effbc66a/attachment.html>
More information about the llvm-dev
mailing list