search for: adjustchaindeps

...1) SU(2) Store "Value A" SU(1) Store "Value A" SU(0) Load "Value A" If MIsNeedChainEdge() returns false for SU(0) and SU(1), SU(0) is inserted into RejectedMemNodes and removed from its MemUses SU list, as this list is cleared. Therefore SU(2) must be handled with adjustChainDeps(), because it needs an edge from SU(0). For some reason adjustChainDeps() was only called for may-aliasing stores. I think this is wrong, as a store will clear the MemUses SU list also in the non-aliasing case. If MIsNeedChainEdge() returns true for SU(0) and SU(1), what happens if MIsNeedChainEdg...

...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 h...

...bility of refactorization / redesign, I wonder what are the main strong points of this implementation right now, in your opinion? The mapping to underlying objects looks nice to me, but I am not sure I understand why to go through the trouble of clearing lists and using a set of RejectMemNodes with adjustChainDeps(). It is very complex code, and I wonder what is gained in the end here. Does anyone have any thoughts about it? Is it to handle huge regions with tons of memory accesses well? Regarding the other two patches: The bugfix I just commited makes sure that adjustChainDeps() is called on an SU regard...

...ing them by analyzing their underlying objects. It is also very confusing to have two "stages" of dependency checking, first by mapping an SU to one or more Values, and then to still "check everything" that may have been missed. I would like to try to remove RejectMemNodes (and adjustChainDeps() and iterateChainSucc()) and then simply not clear the MemUses list (while handling a store). “If an SU gets a Value mapping, keep it”. If that list grows bigger than a certain limit, intelligent alias querying could stop, just as it stops now in iterateChainSucc when *Depth > 200. But it would...

...Tom Stellard; Sergei Larin Subject: Re: ScheduleDAGInstrs.cpp > On Dec 14, 2014, at 3:17 AM, Jonas Paulsson <jonas.paulsson at ericsson.com> wrote: > > Hello again, > > Sorry -- I think I found the problem somewhere else. I was a bit > confused and missed the fact that adjustChainDeps() is called a few > lines down and does just what I wanted :-) > > I would like to instead ask another question: > > Why is I->isCtrl() used in code like > > // Iterate over chain dependencies only. > for (SUnit::const_succ_iterator I = SUb->Succs.begin(), E = SUb-...

Hello again, Sorry -- I think I found the problem somewhere else. I was a bit confused and missed the fact that adjustChainDeps() is called a few lines down and does just what I wanted :-) I would like to instead ask another question: Why is I->isCtrl() used in code like // Iterate over chain dependencies only. for (SUnit::const_succ_iterator I = SUb->Succs.begin(), E = SUb->Succs.end(); I != E; ++I) if (...

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