[LLVMdev] MI DAG constructor indeterminism

Sergei Larin slarin at codeaurora.org
Wed Oct 17 15:10:40 PDT 2012



  So if it is not a feature. then couple questions:


  First, I also do not see an easy way to restructure work sets in this case
- so let's assume std::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,

  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, const SUnit *right) const {

      return left->NodeNum < right->NodeNum;




  typedef std::set<SUnit*, SortSUComp> SortedSUSet;

  SortedSUSet RejectMemNodes;


But in case of Value * as a key - is there any unique ID that is
deterministic and could be used here? As I understand getValueID () is not
unique, or could it be sufficient in this case?

Something as bulky as temporary sorting queue/vector is also possible, but I
do not like it very much.


Any other ideas?







Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by
The Linux Foundation


From: Andrew Trick [mailto:atrick at apple.com] 
Sent: Tuesday, October 16, 2012 10:44 PM
To: Sergei Larin
Cc: 'LLVM Developers Mailing List'
Subject: Re: [LLVMdev] MI DAG constructor indeterminism



On Oct 16, 2012, at 1:43 PM, Sergei Larin <slarin at codeaurora.org> wrote:




  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, and if some algorithm is dependent on the order of
edge traversal, we can have performance and debugging indeterminism. The way
I have discovered it - VLIW scheduler can produce identical cost function
for a pair of SUs, making visitation order the tie breaker, which is not
deterministic per above discussion. For me it is trivial to fix, but I
wonder if this might become a source of well hidden issues in the future.


  I am at this time not proposing anything - a fix is definitely possible,
but I wonder what people think about it before I even consider this a bug.


This looks like a bug. The edge order could even affect some heuristics and
influence codegen.


I don't have a better idea than using SetVector/MapVector for Value* keys.
For SUnits we could just key on NodeNum. Go ahead and file a bug and/or
submit a patch.




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

More information about the llvm-dev mailing list