[llvm-dev] [FPEnv] FNEG instruction

[Cameron McInally via llvm-dev]

On Tue, Sep 25, 2018 at 1:39 PM Sanjay Patel <spatel at rotateright.com> wrote:

> I have 1 concern about adding an explicit fneg op to IR:
>
> Currently, fneg qualifies as a binop in IR (since there's no other way to
> represent it), and we have IR transforms that are based on matching that
> pattern (m_BinOp). With a proper unary fneg instruction, those transforms
> are not going to fire anymore. So I think we'll need to duplicate code to
> account for that difference (or hack the matcher to include fneg?).
>

>
The existing regression tests probably aren't going to show optimization
> failures for those cases*, so I'm not sure how to detect regressions
> without doing an audit of FP transforms in instcombine and other passes.
>

Implementation details. ¯\_(ツ)_/¯

Seriously though, this is interesting and something that I had not
considered. Thinking aloud, what if we caught the FNEG pattern in
the CreateFSub*(...) IRBuilder functions and generated an FNeg instruction
instead? That way we could get rid of the m_FNeg(...) calls altogether.
They would just be replaced with something like: (I.getOpcode() ==
Instruction::FNeg). Any transform that currently uses m_FNeg(...) would
fail to build without an update.

But maybe I'm not considering some substitution that could modify an FSub
instruction in place??


> * Are we proposing to canonicalize "fsub -0.0, X --> fneg X"? As shown in
> the example below, I think that's allowed. If we do that, then we might
> detect some of the affected transforms, but I suspect that we don't have
> that test coverage for most transforms.
>

It sounds reasonable to continue c14n on "fsub -0.0, X --> fneg X". The
problematic case is "fneg X --> fsub -0.0, X".

Although, that does raise the question of who defines undefined behavior:
LLVM or the hardware? I would lean towards falling back to the hardware
behavior. Take integer divide by zero for example. I'd much rather the
hardware define i/0 (e.g. x86 will trap) than LLVM.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180925/a4adb3f9/attachment.html>