llvm dev - May 2020 - DAG Combines that drop flags

While fixing something, I discovered that the DAG combiner will drop the
flags from ISD::FMAXNUM if it is swapping operands to canonicalize the
constant operand on the RHS.
That is presumably because of this code in the DAG combiner:
  // Canonicalize to constant on RHS.
  if (isConstantFPBuildVectorOrConstantFP(N0) &&
      !isConstantFPBuildVectorOrConstantFP(N1))
    return DAG.getNode(N->getOpcode(), SDLoc(N), VT, N1, N0);

As a result, the DAG transformations that are applied to something like
call fast <4 x float> @llvm.maxnum.v4f32(<4 x float> %3, <4 x
float>
zeroinitializer)
vs.
call fast <4 x float> @llvm.maxnum.v4f32(<4 x float>
zeroinitializer, <4 x
float> %3)
will be very different.

I wanted to get some opinions on how prevalent this is and whether there is
any effort ongoing to fix it.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20200513/0cb6873b/attachment.html>

I'm not sure how prevalent it is, but it definitely occurs because the
Flags parameter is optional.

As with the IR equivalent, it should always be correct (not a miscompile)
to silently drop the flags, but that can prevent optimizations as with the
case you're looking at.

I'm not aware of any dedicated effort to fix these, but patches are
welcome. The usual fix is to propagate or intersect flags from existing
nodes.

Alive2 has been good at spotting miscompiles from wrongly propagating flags
in IR. So if you can create an IR-equivalent test, then you could use
Alive2 to confirm correctness. Sadly, the online version of the app seems
to be timing out today:
http://volta.cs.utah.edu:8080/



On Wed, May 13, 2020 at 1:19 PM Nemanja Ivanovic via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> While fixing something, I discovered that the DAG combiner will drop the
> flags from ISD::FMAXNUM if it is swapping operands to canonicalize the
> constant operand on the RHS.
> That is presumably because of this code in the DAG combiner:
>   // Canonicalize to constant on RHS.
>   if (isConstantFPBuildVectorOrConstantFP(N0) &&
>       !isConstantFPBuildVectorOrConstantFP(N1))
>     return DAG.getNode(N->getOpcode(), SDLoc(N), VT, N1, N0);
>
> As a result, the DAG transformations that are applied to something like
> call fast <4 x float> @llvm.maxnum.v4f32(<4 x float> %3, <4
x float>
> zeroinitializer)
> vs.
> call fast <4 x float> @llvm.maxnum.v4f32(<4 x float>
zeroinitializer, <4 x
> float> %3)
> will be very different.
>
> I wanted to get some opinions on how prevalent this is and whether there
> is any effort ongoing to fix it.
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://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/20200513/51561b3a/attachment.html>