search for: aliaschain

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

...parts SU(3): store dataReg0:hi, *addrReg0 SU(4): dataReg1:lo = load *addrReg1(2) // Load a register in two parts SU(5): dataReg1:hi = load *addrReg1 Since the addresses are loaded from memory, the underlying Objs become empty for all MIs. SU(4) and SU(5) get pushed to PendingLoads. SU(3) becomes AliasChain, and edges are added to SU(4) and SU(5). PendingLoads is cleared. SU(2) becomes AliasChain. This time TII->areMemAccessesTriviallyDisjoint() return true, since it can see that addrReg0 with and without offset are disjoint. This was not the case between SU(3) and SU(4), since they were different...

...llegal. Here is my little example again, where SU(0) and SU(2) have a store - load memory dependence which must be modelled with an edge. SUnits: SU(0) Store to address A SU(1) Store to address B SU(2) Load from address 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 missin...

...true (depending on what AA returns), but the AA check is specific to the two instructions being queried, and AA understands how to handle selects/phis/etc. in a reasonable way. Nevertheless, I'm somewhat worried about a subtlety here: I believe that we cannot fail to addChainDependency on the AliasChain because AA is smarter about underlying objects because the AliasChain actually can represent many other dependencies. So maybe when we call addChainDependency with SU on the AliasChain, we need to always pass nullptr for AA. -Hal > > Thanks, > Sanjin > > -----Original Message---...

Hi, I write again regarding buildSchedGraph(), as I am still not happy about things there. I have found at least two examples which do not work out: 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

OK, finally found it. The AliasChain in ScheduleDAGInstrs::buildSchedGraph is not acting as a chain for loads and stores (the head of the chain is not being updated as they are encountered, so dependencies aren't being added solely on the basis of may-aliasing in some cases). Will test a patch. On Fri, 2012-09-21 at 13:04 -0500,...

...returns), but the AA check is specific to the two instructions being > queried, and AA understands how to handle selects/phis/etc. in a > reasonable way. > > Nevertheless, I'm somewhat worried about a subtlety here: I believe > that we cannot fail to addChainDependency on the AliasChain because AA > is smarter about underlying objects because the AliasChain actually > can represent many other dependencies. So maybe when we call > addChainDependency with SU on the AliasChain, we need to always pass > nullptr for AA. > > -Hal > > > > > Thanks...

On Fri, 2012-09-21 at 11:34 -0500, William J. Schmidt wrote: > Hi Sergei, > > Thanks for the response! We just discovered there is likely a bug > happening during post-RA list scheduling. There's an invalid successor > index in the scheduling graph that is probably supposed to be the > missing arc. Starting to investigate further now. This is recorded in >