search for: rejectmemnod

Hi, I would be happy to give it a try :-) The fact that AA was added at a later point explains the situation a bit, as much fewer SUs should end up in RejectMemNodes without it. RejectMemNodes is bad in that it mixes all the SUs together again, after having gone through the work of separating 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 Value...

...::map is needed here. Then the way I understand it, there are five objects that cause the indeterminism: std::map<const Value *, SUnit *> AliasMemDefs, NonAliasMemDefs; std::map<const Value *, std::vector<SUnit *> > AliasMemUses, NonAliasMemUses; std::set<SUnit*> RejectMemNodes; .since all of them at different point of time are traversed begin to end, and as such are affected by pointer value. The case of "std::set<SUnit*> RejectMemNodes; " is easy. Something like this will work: struct SortSUComp { bool operator()(const SUnit *left, c...

...Looking at the possibility 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...

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

...ress A DAG building, bottom-up: SU(2) gets pushed onto PendingLoads. SU(1) becomes AliasChain. A MayAlias edge is added between SU(2) and SU(1). SU(0) becomes AliasChain. TII->areMemAccessesTriviallyDisjoint() says that SU(0) and SU(1) are disjoint, and gets no edge, and SU(1) is inserted into RejectMemNodes (SU(1) and SU(2) were not trivially disjoint). At this moment there is a missing dep between SU(0) and SU(2), and therefore RejectMemNodes MUST be checked so that SU(2) is found and added as a successor to SU(0). In this case,all deps which are isNormalMemory() or isBarrier() MUST be followed....

On Oct 16, 2012, at 1:43 PM, Sergei Larin <slarin at codeaurora.org> wrote: > > Andy, > > This is less of a question but rather a status quo verification… > > We currently have certain indeterminism in MI scheduler DAG construction – it is introduces by the use of std::map/std::set during edge traversal. > Result – a random variation in SUnit edge order

...if the two memory accesses are trivial to analyze or not. Since TII->areMemAccessesTriviallyDisjoint() are called when resetting AliasChain, I think it is necessary to call iterateChainSucs() on the old AliasChain, to make sure there are no SUs succeeding the old AliasChain (and are thus not in RejectMemNodes) that have a dependency on the new AliasChain. Or am I missing something? Very interested in your opinion. I am thinking of something like new_alias_chain: // Chain all possibly aliasing memory references through SU. if (AliasChain) { unsigned ChainLatency = 0;...

Andy, This is less of a question but rather a status quo verification. We currently have certain indeterminism in MI scheduler DAG construction - it is introduces by the use of std::map/std::set during edge traversal. Result - a random variation in SUnit edge order (which will remain fixed thereafter). Logically, it is the same DAG, but topologically it is a slightly different one,

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

.... 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 MIsNeedChainEdge() returns false between SU(2) and SU(1)? The dependency against SU(0) will not be checked, 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...