Assign each question mark a unique negative integer value

[tungld]

IndexExpr currently returns a fix value, -1, for a dimension of question mark during compile time, e.g. when calling shape inference.

This patch assigns question marks with unique negative integer values, starting from -2. This is useful when a input dimension is passed to the output dimension without any computation. In such case, we can check that the output dimension is the same as the input dimension or not via the unique values. However, such checking requires storing IndexExpr for the input inside ShapeHelpr, which requires modifying ShapeHelper. Another PR will be created for that if this patch is accepted.

An optional argument, uniqueQuestionMark is added to IndexExpr::getShape, which is to return negative values (-N) for question marks.

static void getShape(llvm::SmallVectorImpl<IndexExpr> &indexExprList,
                     llvm::SmallVectorImpl<int64_t> &intDimList,
                     bool uniqueQuestionMark);

By default, uniqueQuestionMark = false is used for backward compatibility.

Signed-off-by: Tung D. Le [email protected]

[AlexandreEichenberger]

LGTM, the next step is that when we have a computation with a question mark, the output is a new question mark (unless silly computations such as +0, *1, ...). But when the output is the same as an input question mark, then the same question mark id is used. Not 100% sure if/when new ones are created vs passed as reference.

There is also a bit of an exposure to multi-thread execution with a single value that is incremented without locks. Not sure if it is an issue as of now, could become one in the future.

[AlexandreEichenberger]

I wonder if the IDs should be not used as a single id in the function (scope: function), and then we could use the ids to a hash map of ids... say you get dim0 from %arg0 => id -2, and dim1 from %arg1 => id -3; but later you can detect that dim0 and dim1 must be identical; using a hash map indirection (namely originally -2 hash map to x, -3 hash map to y; but after finding out the equality, the hash map of id -3 is reset to the same as id -2, namely x.

[tungld]

There is also a bit of an exposure to multi-thread execution with a single value that is incremented without locks. Not sure if it is an issue as of now, could become one in the future.

I added a mutex to protect this increment. Thanks!

[jenkins-droid]

Jenkins Linux amd64 Build #8004 [push] Assign each question mar... started at 10:05

[jenkins-droid]

Jenkins Linux ppc64le Build #7068 [push] Assign each question mar... started at 11:08

[jenkins-droid]

Jenkins Linux s390x Build #8021 [push] Assign each question mar... started at 11:06

[jenkins-droid]

Jenkins Linux amd64 Build #8004 [push] Assign each question mar... passed after 1 hr 15 min

[jenkins-droid]

Jenkins Linux ppc64le Build #7068 [push] Assign each question mar... passed after 1 hr 41 min

[jenkins-droid]

Jenkins Linux s390x Build #8021 [push] Assign each question mar... passed after 2 hr 7 min