This is a follow-up patch for the bugfix of https://reviews.llvm.org/D86871.
It fixes the XFAILING SystemZ/fp-mul-14.ll test, and also improves two others.
(D86871 is still pending, and this will be committed afterwards to fix its XFAILing test)
Paths
| Differential D87130
[SelectionDAGBuilder] Remember to copy the FMF flags in visitBinary(). AbandonedPublic Authored by jonpa on Sep 4 2020, 1:44 AM.
Details Summary This is a follow-up patch for the bugfix of https://reviews.llvm.org/D86871. It fixes the XFAILING SystemZ/fp-mul-14.ll test, and also improves two others. (D86871 is still pending, and this will be committed afterwards to fix its XFAILing test)
Diff Detail Event TimelineComment Actions I think this makes sense to me, but I want to point out that this partially reverts the commit https://reviews.llvm.org/D46854. I guess there may be other parts of this commit that should be reverted? Comment Actions
The other thing that was removed by that commit was the propagation of the NoNaNs flag from the experimental_vector_reduce_fmax (/fmin) intrinsic to the replacing VECREDUCE_FMAX (/FMIN) node, but I am not sure why... Comment Actions
Well, the whole approach of D46854 was to remove setting of the FMF in DAG.getNode() everywhere, and instead set the flags via setFlags() after the fact. The point was to be that setting the flags in one place reduces code duplication. However, we're now having the discussion that using setFlags() after the fact may be incorrect in the presence of memoized nodes, and instead we should be always setting flags directly in getNode() -- this basically argues for exactly the opposite direction of what that commit did. Comment Actions
The after the fact handling also caused issue with constrained fp intrinsics which is why they were already excluded. It also had an issue with the vector reduction flag we used to have until I removed it in https://reviews.llvm.org/D76649. Comment Actions
Right - we were trying to make a single point for transferring FMF instead of having every visitXXX() fend for itself. But if there's no way to do it safely/correctly, let's reverse course. At this point, I'm not sure if there is still some problem with always adding flags at getNode() time. Ie, we added the 'Defined' state bit to solve some other flags transfer problem, but is that still needed?
Revision Contents
Diff 289892 llvm/lib/CodeGen/SelectionDAG/SelectionDAGBuilder.cpp
llvm/test/CodeGen/AArch64/fp-const-fold.ll
llvm/test/CodeGen/SystemZ/fp-mul-14.ll
llvm/test/CodeGen/X86/fp-undef.ll
|