[llvm-dev] [FPEnv] FNEG instruction

[Sanjay Patel via llvm-dev]

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>