[LLVMdev] ScheduleDAGInstrs.cpp

[Hal Finkel]

Hi Jonas,

Tom Stellard (cc'd) just recently fixed a bug whereby dependencies on the barrier chain would not be added when the SU had no underlying objects (r223717). Does this fix the problem you're highlighting?

I've also cc'd Sanjin who developed the areMemAccessesTriviallyDisjoint() callback (which I'll note is a relatively-recent addition -- added on Sept. 8th of this year).

In short, if r223717 does not resolve the problem, it sounds like you likely found a bug. What target are you using? I'm trying to get some idea of what your areMemAccessesTriviallyDisjoint() callback is doing.

 -Hal

----- Original Message -----
> From: "Jonas Paulsson" <jonas.paulsson at ericsson.com>
> To: hfinkel at anl.gov, llvmdev at cs.uiuc.edu
> Cc: "Mattias Eriksson V" <mattias.v.eriksson at ericsson.com>
> Sent: Monday, December 8, 2014 8:06:27 AM
> Subject: ScheduleDAGInstrs.cpp
>
> 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
> 
> /\
> 
> / \ // Aliasing memory accesses
> 
> SU2
> 
> 
> 
> all SUs have memory operands, but the underlying objects vectors are
> empty.
> 
> SU1 became AliasChain, added dep to SU2, and cleared the lists for
> aliasing memory accesses.
> 
> SU0 has a dependency towards SU2, but towards SU1 it is trivially
> disjoint, and therefore it gets
> 
> no dependency to SU1 and * neither to SU2 *. The AliasChain concept
> is bypassed.
> 
> 
> 
> I don’t understand how it can first be assumed that an SU becomes
> AliasChain, and then an SU
> 
> with lower NodeNum that may alias is allowed to skip its dep to the
> AliasChain?
> 
> The BarrierChain is never skipped because addPred() is called
> directly, and I don’t see how it is
> 
> safe to skip the AliasChain for aliasing SUs, I think it should
> always be added? In other words,
> 
> it may be that SU0 has a dep towards SU2 in the example, but not
> towards SU1, so therefore it
> 
> is not safe to skip this dep.
> 
> 
> 
> Calling addPred() instead of addChainDependency() for AliasChain
> should fix this, however it
> 
> would lead to overly constrained DAGs compared to putting the edges
> where they actually should
> 
> be (SU0<-SU2 instead of SU0<-SU1).
> 
> 
> 
> Most thankful for any help,
> 
> 
> 
> Jonas Paulsson
> 
> 
> 
> 

-- 
Hal Finkel
Assistant Computational Scientist
Leadership Computing Facility
Argonne National Laboratory