[PATCH] D151934: InstCombine: Recognize fneg when performed as bitcasted integer

Thu Aug 31 15:48:04 PDT 2023

goldstein.w.n added a comment.

In D151934#4632720 <https://reviews.llvm.org/D151934#4632720>, @efriedma wrote:

> LGTM
>
>> I think you have no right to complain once your code touches fast math code. It's not a miscompile if you permitted it. The sign bit changing would have to originate from the fast math imbued instruction
>
> The point here is that there should be a boundary between fast and non-fast instructions: if you have a "fast" algorithm, you should be able to use its output in non-"fast" code without infecting it.
>
> But I think it only ends up being an issue with the function-wide flag, not the per-instruction flags, so anyone who cares about that can just avoid setting that bit.
>
>> imo should require a cast back to float. If we are keeping it as an integer, I think xor is more recognizable/canonical.
>
> fneg seems more likely to actually correspond to a natively supported instruction, and more likely to be combined with adjacent operations.

Depends which context you are talking about. If its with other float instructions sure. If its with integer instructions I'm not so sure.
Thats why I think it should be (bitcast (xor (bitcast))` not just `(xor (bitcast))`.

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D151934/new/

https://reviews.llvm.org/D151934