[llvm-dev] [FPEnv] FNEG instruction

[Sanjay Patel via llvm-dev]

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>