[LLVMdev] ScheduleDAGInstrs.cpp

Jonas Paulsson jonas.paulsson at ericsson.com
Mon Dec 8 06:06:27 PST 2014


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


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20141208/f26332e5/attachment.html>


More information about the llvm-dev mailing list