DAG Combines that drop flags

Project Infrastructure LLVM Dev List Archives
1

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.

2

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/