search for: d19391

Regarding non-IEEE targets: yes, we definitely support those, so we do have to be careful about not breaking them. I know because I have broken them. :) See the discussion and related links here: https://reviews.llvm.org/D19391 But having an exactly specified fneg op makes that easier, not harder, as I see it. Unfortunately, if a target doesn't support this op (always toggle the sign bit and only the sign bit), then we can't canonicalize 'fsub -0.0, X' to 'fneg X' because those are not identical o...

...e want 1 or both of fneg and fneg_constrained (and if we choose both, then I assume we'd also add fabs_constrained and copysign_constrained). I don't see why we want those redundancies. As discussed here, we already can't canonicalize to the FP bitops in IR because of non-IEEE targets (D19391). In IR and the backend, you don't want to over-constrain allowable optimizations. Fneg folds shouldn't be disabled just because we changed the FP exception state? On Mon, Oct 1, 2018 at 12:20 PM Cameron McInally <cameron.mcinally at nyu.edu> wrote: > On Thu, Sep 27, 2018 at 10:1...

I have no example side effects in hand. But LLVM targets a bunch of architectures, and who knows what the future holds. So it may be prudent to not promise too much so as to leave ourselves an escape hatch. Doesn’t LLVM target some chips that have floating point instruction sets that are not IEEE compliant? Can we be certain that no new LLVM target will ever have to jump through hoops to avoid