[llvm-dev] DAG Combines that drop flags
Sanjay Patel via llvm-dev
llvm-dev at lists.llvm.org
Wed May 13 12:59:23 PDT 2020
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
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:
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) &&
> 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>
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the llvm-dev