Bugfix for missed dependency from store to load in buildSchedGraph().

Background: When handling underlying objects for a store, the vector
of previous mem uses, mapped to the same Value, is afterwards cleared
(regardless of ThisMayAlias). This means that during handling of the
next store using the same Value, adjustChainDeps() must be called,
otherwise a dependency might be missed.

For example, three spill/reload (NonAliasing) memory accesses using
the same Value 'a', with different offsets:

    SU(2): store  @a
    SU(1): store  @a, Offset:1
    SU(0): load   @a

In this case we have:

* SU(1) does not need a dep against SU(0). Therefore,SU(0) ends up in
  RejectMemNodes and is removed from the mem-uses list (AliasMemUses
  or NonAliasMemUses), as this list is cleared.

* SU(2) needs a dep against SU(0). Therefore, SU(2) must check
  RejectMemNodes by calling adjustChainDeps().

Previously, for store SUs, adjustChainDeps() was only called if
MayAlias was true, missing the S(2) to S(0) dependency in the case
above. The fix is to always call adjustChainDeps(), regardless of
MayAlias, since this applies both for AliasMemUses and
NonAliasMemUses.

No testcase found for any in-tree target.

llvm-svn: 228686

lib/CodeGen/ScheduleDAGInstrs.cpp

@@ -991,11 +991,9 @@ void ScheduleDAGInstrs::buildSchedGraph(AliasAnalysis *AA,
         // Add dependence on alias chain, if needed.
         if (AliasChain)
           addChainDependency(AAForDep, MFI, SU, AliasChain, RejectMemNodes);
-        // But we also should check dependent instructions for the
-        // SU in question.
-        adjustChainDeps(AA, MFI, SU, &ExitSU, RejectMemNodes,
-                        TrueMemOrderLatency);
       }
+      adjustChainDeps(AA, MFI, SU, &ExitSU, RejectMemNodes,
+                      TrueMemOrderLatency);
     } else if (MI->mayLoad()) {
       bool MayAlias = true;
       if (MI->isInvariantLoad(AA)) {