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 ops (denorms, NaN). So that leads back to the m_FNeg abstraction - it will have to match both ops to not lose optimizations. On Wed, Sep 26, 2018 at 2:04 PM Cameron McInally via llvm-dev < llvm-dev at lists.llvm.org> wrote:> On Wed, Sep 26, 2018 at 3:36 PM Kevin Neal <Kevin.Neal at sas.com> wrote: > >> 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 side effects simply because we >> promised that fneg would never, ever have any side effects? >> >> >> >> Assuming we do promise no side effects from fneg, ever and forever, then >> the documentation should say that clearly. >> > > Maybe I'm misunderstanding the LangRef copy, but the promise of 'no side > effects' is really saying that trapping behavior is not guaranteed to be > preserved under optimizations. FNEG(X) never has side effects (it never > traps). It is a bitwise operation. > > Now changing FNEG(X) into FSUB(-0.0, X) is a different conversation. Those > two operations do not give bitwise identical results for all inputs. So, > it's really not safe to replace one with the other [well, arguably only > FNEG(X) --> FSUB(-0.0, X) isn't safe]. So, as long as we don't make an > unsafe transformation, which can set incorrect bits if we do make it, then > I don't foresee a problem with side-effects on FNEG. > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180927/409b7ede/attachment.html>
On Thu, Sep 27, 2018 at 10:14 AM Sanjay Patel <spatel at rotateright.com> wrote:> 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 ops (denorms, NaN). > > So that leads back to the m_FNeg abstraction - it will have to match both > ops to not lose optimizations. >I like this idea. So how do we get official approval to begin this work? -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20181001/bfff9b5e/attachment.html>
I don't see any controversy for the preliminary requirement of removing BinaryOperator::isFNeg() and friends, so start with that? That work may reveal other potential regressions that we can patch in advance too. Other than that, I think there's really only a question of do we 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:14 AM Sanjay Patel <spatel at rotateright.com> > wrote: > >> 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 ops (denorms, NaN). >> >> So that leads back to the m_FNeg abstraction - it will have to match both >> ops to not lose optimizations. >> > > I like this idea. > > So how do we get official approval to begin this work? >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20181001/a5f6e724/attachment.html>