Optimzations make assumption about function names

[smaillet]

Given the following module as an input

define double @anon_expr_1() {
entry:
  %calltmp = call double @cos(double 1.234000e+00)
  ret double %calltmp
}

declare double @cos(double)

optimization with a minimal set of passes "simplifycfg,instcombine,reassociate,gvn" will produce the following module:

define double @anon_expr_1() {
entry:
  %calltmp = call double @cos(double 1.234000e+00)
  ret double 0x3FD526571FE8C7A5
}

declare double @cos(double)

NOTE: The return of this function is the IEEE Hex form of 0.33046510807172985 which is the mathematical Cosine of 1.234. Thus, the optimizations have Assumed that the function named cos is in fact the mathematical function of the same name common in C runtime libraries - but it doesn't KNOW that. It could well be that this is just a function that happens to have the name cos (and has NO reliance on the C runtime). The expectation is that this does something completely different that might even have side effects so ignoring the return value and substituting a const is just WRONG behavior. (One would hope that subsequent optimization stages would not remove the call due to the possibility of side effects, but ignoring the return and substituting a const value is still wrong)

[nikic]

You can place the nobuiltin attribute on the call to disable libcall recognition.

Like this:

define double @anon_expr_1()  {
entry:
  %calltmp = call double @cos(double 1.234000e+00) nobuiltin
  ret double %calltmp
}

declare double @cos(double)

[nikic]

Alternatively, you can also use TargetLibraryInfo to configure which libcalls are available in your environment. disableAllFunctions() disables all libcalls.

[smaillet]

requiring the "nobuiltin" seems like a dangerous form of OPT-IN to me. (Note, I found this when converting OLD code from LLVM 10 to an RC of LLVM 20 so it wasn't always like this). Use of the TargetLibraryInfo is something to consider, except that this is NOT currently using any target library. At most such a thing is tied to the TargetMachine, which is currently set to "NULL" for the optimization runs as there isn't any particular target yet. (Just IR). I am also constrained by the LLVM-C API so, no access to the underlying C++. Sadly, the LLVM-C API has no mention of TargetLibraryInfo. So, to use that I'd need some sort of custom extension wrapper.