Fix a bug in SROA savings estimation.

[eraman]

Summary

While estimating SROA savings, we want to see if an address is derived off an alloca in the caller. For store instructions, operand 1 is the address operand, but the current code checks against operand 0. For clarity, I have used getPointerOperand for store and load instructions.

[eraman]

Added a test case where callee's inlining depends on the store and load instructions being considered SROA candidates.

[chandlerc]

This looks good, thanks!

[eraman]

This has been submitted long time back.

lib/Analysis/IPA/InlineCost.cpp

bool CallAnalyzer::visitBinaryOperator(BinaryOperator &I) {
   disableSROA(RHS);
 
   return false;
 }
 
 bool CallAnalyzer::visitLoad(LoadInst &I) {
   Value *SROAArg;
   DenseMap<Value *, int>::iterator CostIt;
-  if (lookupSROAArgAndCost(I.getOperand(0), SROAArg, CostIt)) {
+  if (lookupSROAArgAndCost(I.getPointerOperand(), SROAArg, CostIt)) {
     if (I.isSimple()) {
       accumulateSROACost(CostIt, InlineConstants::InstrCost);
       return true;
     }
 
     disableSROA(CostIt);
   }
 
   return false;
 }
 
 bool CallAnalyzer::visitStore(StoreInst &I) {
   Value *SROAArg;
   DenseMap<Value *, int>::iterator CostIt;
-  if (lookupSROAArgAndCost(I.getOperand(0), SROAArg, CostIt)) {
+  if (lookupSROAArgAndCost(I.getPointerOperand(), SROAArg, CostIt)) {
     if (I.isSimple()) {
       accumulateSROACost(CostIt, InlineConstants::InstrCost);
       return true;
     }
 
     disableSROA(CostIt);
   }