search for: addchaindepend

...cked, because it is not in RejectMemNodes, nor in the MemUses SU list. 2) SU(2) Load "Value A" SU(1) Store "Value A" SU(0) Store "Value A" If not using alias analysis, then the MemDefs list is cleared after *maybe* having inserted an edge from SU(0) to SU(1) with addChainDependency(). If there was not an edge inserted, then SU(2) must get a chance to check its deps against SU(0) by use of adjustChainDeps(). Again, this is only done if MayAlias is true. I suspect therefore that areMemAccessesTriviallyDisjoint() is currently used in a very dangerous way, since it might get...

Hi, Can anyone help me to understand the ScheduleDAGInstrs::buildSchedGraph() method? I find the handling of AliasChain is disturbing since: 1. A new alias chain add deps to all possibly aliasing SUs, and then clears those lists. 2. When AliasChain is present, the addChainDependency() method is called, but the target hook areMemAccessesTriviallyDisjoint() called inside MIsNeedChainEdge() allows this edge to be skipped. This means that I get a case where SU0 SU1, AliasChain /\ / \...

...ed. Here's my thinking: There is a call to getUnderlyingObjectsForInstr, and that needs to be there because of how the calling code groups the resulting SUs by underlying object. Specifically, ScheduleDAGInstrs::buildSchedGraph first gets the underlying objects for a value, and then only calls addChainDependency on SUs that share one of these underlying objects. The reason why we insist on having an identified underlying object is so that we know we're not being non-uniformly limited by the depth constraint. I mean the following. Assume I have two globals (@a and @b), and I have a third value forme...

...r opinion. I am thinking of something like new_alias_chain: // Chain all possibly aliasing memory references through SU. if (AliasChain) { unsigned ChainLatency = 0; if (AliasChain->getInstr()->mayLoad()) ChainLatency = TrueMemOrderLatency; addChainDependency(AAForDep, MFI, SU, AliasChain, RejectMemNodes, ChainLatency); + + // Since TII->areMemAccessesTriviallyDisjoint() is not + // complete, iterate all chain successors of old + // AliasChain. Otherwise, if an address is stored in two + //...

...> There is a call to getUnderlyingObjectsForInstr, and that needs to be > there because of how the calling code groups the resulting SUs by > underlying object. Specifically, ScheduleDAGInstrs::buildSchedGraph > first gets the underlying objects for a value, and then only calls > addChainDependency on SUs that share one of these underlying objects. > The reason why we insist on having an identified underlying object is > so that we know we're not being non-uniformly limited by the depth > constraint. I mean the following. Assume I have two globals (@a and > @b), and I...

...something like > > new_alias_chain: > // Chain all possibly aliasing memory references through SU. > if (AliasChain) { > unsigned ChainLatency = 0; > if (AliasChain->getInstr()->mayLoad()) ChainLatency = TrueMemOrderLatency; > addChainDependency(AAForDep, MFI, SU, AliasChain, RejectMemNodes, > ChainLatency); > + > + // Since TII->areMemAccessesTriviallyDisjoint() is not > + // complete, iterate all chain successors of old > + // AliasChain. Otherwise, if an address is st...

...are using 15, 22 and 27 GB of memory but do not appear to grow further. This worked fine in the past, so appears to be a regression. These stacks seem to be prevalent: #0 0x0000000001850588 in llvm::SUnit::addPred(llvm::SDep const&, bool) () #1 0x0000000001855265 in llvm::ScheduleDAGInstrs::addChainDependency(llvm::SUnit*, llvm::SUnit*, unsigned int) () #2 0x0000000001855519 in llvm::ScheduleDAGInstrs::addChainDependencies(llvm::SUnit*, llvm::ScheduleDAGInstrs::Value2SUsMap&) () #3 0x000000000185f3ba in llvm::ScheduleDAGInstrs::buildSchedGraph(llvm::AAResults*, llvm::RegPressureTracker*, llvm:...