| Issue |
202453
|
| Summary |
llvm allows `fabs nsz` to return -0
|
| Labels |
new issue
|
| Assignees |
|
| Reporter |
jlebar
|
The langref says that nnan and ninf mean we can assume an instruction's arguments and results are not nan/inf. But it says that nsz means we can assume that an op's *inputs* can be switched between +0 and -0. It does not say that we can switch an op's *output* from +0 to -0.
It this is what we mean to say, then in particular `fabs nsz -0 == +0`, and indeed the nsz flag on fabs is meaningless.
Several folds replace `f(fabs nsz %x)` with `f(%x)` even when `f` can observe the difference between +0 and -0. For example
```
case Intrinsic::fabs: {
KnownFPClass KnownClass = computeKnownFPClass(Op0, fcAllFlags, Q);
if (KnownClass.SignBit == false)
return Op0;
if (KnownClass.cannotBeOrderedLessThanZero() &&
KnownClass.isKnownNeverNaN() && FMF.noSignedZeros())
return Op0;
```
Before I send a patch fixing this, I wanted to check if maybe this is a bug in the langref and we actually mean to specify it in a way such that `fabs nsz 0` can equal -0?
![]()
_______________________________________________
llvm-bugs mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
