search for: arememaccessestriviallydisjoint

...rstand 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 /\ / \ // Aliasing memory accesses SU2 all SUs have memory operand...

...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 address registers (with the same value). The result is that there is no edge added between SU(2) and SU(3) and not to SU(4) since PendlingLoad...

...ence 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 missing dep between SU(0) and SU(2), and therefore RejectMemNodes MUST be checked so that SU(2) is found and added as a suc...

...e(), and is separate from D8705) I found out that the MIScheduler (pre-ra) could not handle a simple test case (test/CodeGen/SystemZ/alias-01.ll), with 16 independent load / add / stores. The buildSchedGraph() put too many edges between memory accesses, because 1) There was no implementation of areMemAccessesTriviallyDisjoint() for SystemZ. 2) Type Based Alias Analysis (TBAA) was not used. I have gotten rid of the edges on an experimental level, and would now like some help and feedback: 1): It seems common for targets to check for the same virtual address register and then figure out via offsets/sizes if they over...

...s 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 lucky in just one of two (equivalent) queries, and a dependency might be missed later on as seen above. Or am I missing something here? Senjin, I am working on an out-of-tree target. The problem I had was the first scenario in #1, an...

...ink adjustChainDeps() must be called regardless of MayAlias while handling a store. This problem was found on an out-of-tree target, and no test case can be provided for an official target. Let me know if I can commit this patch, or if you have any comments. /Jonas PS. Sanjin, regarding TII->areMemAccessesTriviallyDisjoint(), my target does the same things as you mentioned: register / offset based analysis, both pre/post RA. It is adding very little improvement over AA, it seems. I don't have any failing test cases right now, so it may be that this patch actually fixed my problem. However, right now it is confusi...

...s of MayAlias while handling a store. > > This problem was found on an out-of-tree target, and no test case can > be provided for an official target. > > Let me know if I can commit this patch, or if you have any comments. > > /Jonas > > PS. Sanjin, regarding TII->areMemAccessesTriviallyDisjoint(), my > target does the same things as you mentioned: register / offset based > analysis, both pre/post RA. It is adding very little improvement over > AA, it seems. I don't have any failing test cases right now, so it may > be that this patch actually fixed my problem. > How...

Hello, While tuning the MIScheduler for my target, I discovered a code that unnecessarily restricts the scheduler. I think this is a bug, but I would appreciate a second opinion. In file ScheduleDAGInstrs.cpp, the function MIsNeedChainEdge determines whether two MachineInstrs are ordered by a memory dependence. It first runs through the standard criteria (Do both instructions access memory?

On 9/27/19 7:33 AM, Matt Arsenault via llvm-dev wrote: > > >> On Sep 27, 2019, at 09:07, Björn Pettersson A via llvm-dev >> <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: >> >> Obviously we do not store into two locations (it is still a single >> two byte store). >> So is it (always) correct to interpret the list of