| Issue |
130172
|
| Summary |
Optimzations make assumption about function names
|
| Labels |
new issue
|
| Assignees |
|
| Reporter |
smaillet
|
Given the following module as an input
```llvm ir
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:
```llvm ir
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 remove the call due to the possibility of side effects, but ignoring the return and substituting a const value is still wrong)
![]()
_______________________________________________
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
