[CFLGraph] Add support for unary fneg instruction.

[craig.topper]

Summary

I don't know much about this analysis so I'm not sure the best way to test this.

[cameron.mcinally]

I don't know much about this pass either, but it looks like test/Analysis/CFLAliasAnalysis is the right place.

I hacked up Steensgaard/constant-over-index.ll to include an fneg and that seems to exercise the code. Your guess is better than mine if it's sufficient coverage or not.

--- a/llvm/test/Analysis/CFLAliasAnalysis/Steensgaard/constant-over-index.ll
+++ b/llvm/test/Analysis/CFLAliasAnalysis/Steensgaard/constant-over-index.ll
@@ -18,7 +18,9 @@ loop:
 
   %p.0.i.0 = getelementptr [3 x [3 x double]], [3 x [3 x double]]* %p, i64 0, i64 %i, i64 0
 
-  store volatile double 0.0, double* %p3
+  %neg = fneg double 0.0
+
+  store volatile double %neg, double* %p3
   store volatile double 0.1, double* %p.0.i.0

To be clear, I'm not suggesting that as a test -- just proving that the new code is exercised with this change.

[george.burgess.iv]

Thanks you both! LGTM with a test, assuming that adding the test is straightforward.

Similar comments as on D62790: presuming that fneg doesn't operate on pointers, this code will just be a nop. If CFL* gets revived someday, we might end up trying to extract useful information from the flow of values through non-pointer-types, but as it stands, we just treat any inttoptr as magic and are conservative about it.

I suppose that if we wanted to be more explicit about this, we could have add*Edge return whether or not an edge was added, and just assert(!add*Edge(...)) for all FP ops, but that's out of the scope of this patch IMO.

it looks like test/Analysis/CFLAliasAnalysis is the right place

+1. CFLGraph bits are shared between both the Andersen/ and Steensgaard/ subdirectories, so it shouldn't make a difference which one we place the coverage line in.

just proving that the new code is exercised with this change

For the reasons noted above, "it doesn't crash" is probably the best test we can have here at the moment.

[craig.topper]

Stuck an fneg into an existing test that already had an fmul. This executes the visitUnaryOperator function. The constant expr path is still untested. But I think all the binary ops are untested there as well.

[george.burgess.iv]

Fair enough; thanks again!

llvm/lib/Analysis/CFLGraph.h

public:
 
     void visitBinaryOperator(BinaryOperator &Inst) {
       auto *Op1 = Inst.getOperand(0);
       auto *Op2 = Inst.getOperand(1);
       addAssignEdge(Op1, &Inst);
       addAssignEdge(Op2, &Inst);
     }
 
+    void visitUnaryOperator(UnaryOperator &Inst) {
+      auto *Src = Inst.getOperand(0);
+      addAssignEdge(Src, &Inst);
+    }
+
     void visitAtomicCmpXchgInst(AtomicCmpXchgInst &Inst) {
       auto *Ptr = Inst.getPointerOperand();
       auto *Val = Inst.getNewValOperand();
       addStoreEdge(Val, Ptr);
     }
 
     void visitAtomicRMWInst(AtomicRMWInst &Inst) {
       auto *Ptr = Inst.getPointerOperand();
void visitConstantExpr(ConstantExpr *CE) {
       case Instruction::ICmp:
       case Instruction::FCmp:
       case Instruction::ShuffleVector: {
         addAssignEdge(CE->getOperand(0), CE);
         addAssignEdge(CE->getOperand(1), CE);
         break;
       }
 
+      case Instruction::FNeg: {
+        addAssignEdge(CE->getOperand(0), CE);
+        break;
+      }
+
       default:
         llvm_unreachable("Unknown instruction type encountered!");
       }
     }
   };
 
   // Helper functions