[llvm-dev] [FPEnv] FNEG instruction

[Kevin Neal via llvm-dev]

If we don’t have constrained intrinsics for some of the fp math instructions then aren’t we risking non-strict optimizations?

--
Kevin P. Neal
SAS/C and SAS/C++ Compiler
Host Research and Development
SAS Institute, Inc.



From: Sanjay Patel <spatel at rotateright.com>
Sent: Monday, October 01, 2018 5:41 PM
To: cameron.mcinally at nyu.edu
Cc: Kevin Neal <Kevin.Neal at sas.com>; llvm-dev <llvm-dev at lists.llvm.org>
Subject: Re: [llvm-dev] [FPEnv] FNEG instruction


EXTERNAL
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<mailto:cameron.mcinally at nyu.edu>> wrote:
On Thu, Sep 27, 2018 at 10:14 AM Sanjay Patel <spatel at rotateright.com<mailto: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/20181002/234ef760/attachment.html>