| Issue |
97837
|
| Summary |
FP optimization wrong wrt NaNs?
|
| Labels |
|
| Assignees |
|
| Reporter |
regehr
|
here's a function:
```llvm
define float @f(float %0) {
%2 = fpext float %0 to double
%3 = fptrunc double %2 to float
ret float %3
}
```
InstCombine elides the ext/trunc and just returns %0. Alive finds that this optimization changes the behavior-- the original code quiets an incoming SNaN, whereas the optimized code obviously doesn't do that (sorry, no CE link, this example times out there)
```
Example:
float %#0 = #x7f808003 (SNaN)
Source:
double %#2 = #x7ff8000000000000 (QNaN)
float %#3 = #x7fc00000 (QNaN)
Target:
Source value: #x7fc00000 (QNaN)
Target value: #x7f808003 (SNaN)
```
our understanding is that this behavior is a violation of what LLVM is currently trying to do. is Alive right here, or LLVM? thanks
cc @RalfJung @nunoplopes
![]()
_______________________________________________
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
