[llvm-dev] how to simplify FP ops with an undef operand?
Philip Reames via llvm-dev
llvm-dev at lists.llvm.org
Wed Feb 28 15:06:11 PST 2018
On 02/27/2018 06:29 PM, Sanjay Patel via llvm-dev wrote:
> %y = fadd float %x, undef
> Can we simplify this?
> Currently in IR, we do nothing for fadd/fsub/fmul. For fdiv/frem, we
> propagate undef. The code comment for fdiv/frem says:
> "the undef could be a snan"
> If that's correct, then shouldn't it be the same for fadd/fsub/fmul?
> But this can't be correct because we support targets that don't raise
> exceptions...and even targets that raise exceptions do not trap by
> default on snan?
Fair warning, the following is a tangent from the actual topic under
discussion... It's only vaguely connected to the example at hand and is
mostly a reaction to a collection of comments in various previous
floating point discussion threads.
The reasoning here worries me. The semantics of LLVM IR is specified
independently of what any particular target does. Referring to target
behavior to decide on appropriate semantics for a particular
optimization seems inherently problematic. We should instead use LLVM
IR's stated semantics to decide legality. We should only use target
semantics to help shape proposals to change the IR semantics.
To be specific, something along the lines of the following seems
entirely reasonable: "LLVM IR allows us to perform the following
optimization here, but doing that would radically complicate the
lowering on target X which doesn't support Y. Should we change the IR
specification to Z?" On the other hand, reasoning like "Target X
doesn't do Y, so this optimization can't be legal" are problematic.
If the code is more specific than the LangRef, we should propose a
clarification to the LangRef. The specification for floating point
semantics is admittedly a weakness in the current version. Rather than
working around it, we should fix that.
End vaguely related rant, thanks for reading!
More information about the llvm-dev