[mlir] Add DenseUI32ArrayAttr

[amrami]

No description provided.

[joker-eph]

Can you add a motivation to this PR?

This was not included very intentionally, so we should really carefully look into whether we want to add it now.

[amrami]

@joker-eph - I have a op with permutation attribute. Since this is a permutation of the tensor dims, I know that values are >= 0.
So I find it more accurate to declare the attribute as DenseUI32ArrayAttr.

I looked now at the existing code, and saw that linalg TransposeOp uses DenseI64ArrayAttr:$permutation.
Then the verifier validates that no negative numbers are there:

LogicalResult TransposeOp::verify() {
  ArrayRef<int64_t> permutationRef = getPermutation();

  if (!isPermutationVector(permutationRef))
    return emitOpError("permutation is not valid");
...

Where

bool mlir::isPermutationVector(ArrayRef<int64_t> interchange) {
  assert(llvm::all_of(interchange, [](int64_t s) { return s >= 0; }) &&
         "permutation must be non-negative");
  llvm::SmallDenseSet<int64_t, 4> seenVals;
  for (auto val : interchange) {
    if (seenVals.count(val))
      return false;
    seenVals.insert(val);
  }
  return seenVals.size() == interchange.size();
}

I believe the permutation could be DenseUI64ArrayAttr (which can be added too)

[joker-eph]

Using "unsigned" to model "positive quantities" is a common C++ mistake, to the point where multiple coding guidelines are actively discouraging to use unsigned integer.

A lot has been written about this, good references are [unsigned: A Guideline for Better Code] https://www.youtube.com/watch?v=wvtFGa6XJDU) and Garbage In, Garbage Out: Arguing about Undefined Behavior..., as well as this panel discussion:

• https://www.youtube.com/watch?v=Puio5dly9N8#t=12m12s
• https://www.youtube.com/watch?v=Puio5dly9N8#t=42m40s

Other coding guidelines already embrace this:

• http://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#Res-signed
• http://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#Res-unsigned
• https://google.github.io/styleguide/cppguide.html#Integer_Types

It is rare that overflowing (and wrapping) an unsigned integer won't trigger a program bug when the overflow was not intentionally handled. Using signed arithmetic means that you can actually trap on over/underflow and catch these bugs (when using fuzzing for instance).

Chandler explained this nicely in his CPPCon 2016 talk "Garbage In, Garbage Out: Arguing about Undefined Behavior...". I encourage to watch the full talk but here is one relevant example: https://youtu.be/yG1OZ69H_-o?t=2006 , and here he mentions how Google experimented with this internally: https://youtu.be/yG1OZ69H_-o?t=2249

Unsigned integer also have a discontinuity right to the left of zero. Suppose A, B and C are small positive integers close to zero, say all less than a hundred or so. Then given: A + B > C
and knowing elementary school algebra, one can rewrite that as: A > B - C
But C might be greater than B, and the subtraction would produce some huge number. This happens even when working with seemingly harmless numbers like A=2, B=2, and C=3.