[LLVMdev] MI DAG constructor indeterminism

[Sergei Larin]

Andy, 

 

  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,
NonAliasMemUses;

  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?

 

Thanks.

 

Sergei

 

---

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:





 

Andy,

 

  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.

 

Thanks!

-Andy

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