Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
- Build Status
Buildable 188265 Build 284422: arc lint + arc unit
Event Timeline
mlir/include/mlir/Dialect/SparseTensor/IR/SparseTensorOps.td | ||
---|---|---|
395 | I would not present this as a COO case per se. What it really does is sorting parallel arrays, with one array of one type, and all other arrays of index type. For example, in compress, we will need to sort a *single* array of type index, so that can only be expressed as sparse_tensor.sort %n, %values with index typed %values. But will that work too? | |
400 | Please add the usual disclaimer (note that we have two sections, pure ops, and ops that are (for now) defined with side effects. Note that this operation is "impure" in the sense that its behavior is solely defined by side-effects and not SSA values. The semantics may be refined over time as our sparse abstractions evolve. | |
404 | coordinates | |
mlir/lib/Dialect/SparseTensor/IR/SparseTensorDialect.cpp | ||
457 | ironically, our errors do not follow our comment rule, | |
462 | Please use for (size_t i = 0, e = getCoordinates().size(); i < e; i++) idiom |
mlir/include/mlir/Dialect/SparseTensor/IR/SparseTensorOps.td | ||
---|---|---|
398 | It is ambiguous, how about "so that the resulting coordinates are in lexicographical order when putting together". (or something better) for example: are sorted into not | |
403 | Maybe change it to "This operator updates coordinates and values in place"? | |
416 | Is it the trick to omit jointly when value is empty? | |
mlir/lib/Dialect/SparseTensor/IR/SparseTensorDialect.cpp | ||
519 | why not for (Value t : operands)? since you are not using i other than operands[i] |
mlir/lib/Dialect/SparseTensor/IR/SparseTensorDialect.cpp | ||
---|---|---|
524 | This reminds me of the debate I had with Wren about whether or not support dynamic dimension for concat. While I believe here dynamic support is crucial, but can we add a disclaimer that it is UB when dynamic sized array have unmatched dimensions? |
Use xs and ys instead of coordinates and values per offline discussion.
Address review comment.
Yeah, looking good. A few nits on doc and verification
mlir/include/mlir/Dialect/SparseTensor/IR/SparseTensorOps.td | ||
---|---|---|
395 | Please update short summary as well, something like Sorts the arrays in xs and ys lexicographically on the integral values found in the xs list | |
399 | Please make a note that, thus, the order in which arrays appear in the xs list matter, before going into the example | |
408 | Don't we want to relax this to, all arrays should have length >= n | |
mlir/lib/Dialect/SparseTensor/IR/SparseTensorDialect.cpp | ||
524 | I think it is safe to state that all arrays should have length >= n or otherwise UB results. | |
528 | as above, do we really want same length, or just >= n? | |
mlir/test/Dialect/SparseTensor/invalid.mlir | ||
472 | I don't think all custom verification errors are covered yet? |
mlir/include/mlir/Dialect/SparseTensor/IR/SparseTensorOps.td | ||
---|---|---|
398 | Revise this part per offline discussion and also add an example. PTAL. | |
408 | Yes, we can. | |
416 | Yes. | |
mlir/lib/Dialect/SparseTensor/IR/SparseTensorDialect.cpp | ||
519 | Thanks! | |
524 | Add comment and description in the td definition. | |
528 | Change to allow >= n. | |
mlir/test/Dialect/SparseTensor/invalid.mlir | ||
472 | The test doesn't work possible due to some parse issue. Add a TODO. |
mlir/include/mlir/Dialect/SparseTensor/IR/SparseTensorOps.td | ||
---|---|---|
391 | Can you check to see if there's a way to use the SameOperandsShape and SameOperandsElementType traits but restricting them to the memrefs in $xs (rather than for all operands to the op)? If we can, that'd save a lot of code in the verifier. Though last time I checked there wasn't a clean way to do this | |
393 | As mentioned in chat, you should use Variadic<...> {let minSize = 1;} for this. I don't think you can do the let inline, so you can just float out the definition class NonemptyVariadic<Type type> : Variadic<type> { let minSize = 1; } and then use NonemptyVariadic<...>:$xs | |
397–405 | It might help clarify things to say that the relationship between memrefs is as if we did zip(zip(xs), zip(ys)) to obtain a list of pairs of lists, and then lexicographically sort the outer list on the first component of the pair. | |
mlir/lib/Dialect/SparseTensor/IR/SparseTensorDialect.cpp | ||
514 | Minor nit, but I'd rather this be named xsType (or xsTp or xtp) |
mlir/include/mlir/Dialect/SparseTensor/IR/SparseTensorOps.td | ||
---|---|---|
403 | put `` on the zip part, so that it looks like code in our online doc as well | |
415 | perhaps mention UB if this condition is not met (since we don't have runtime checks for that) | |
mlir/lib/Dialect/SparseTensor/IR/SparseTensorDialect.cpp | ||
524 | Nit: if n == 0, you can skip the whole loop that tests this |
Fix comments to address review feedback.
mlir/lib/Dialect/SparseTensor/IR/SparseTensorDialect.cpp | ||
---|---|---|
524 | Per offline discussion, I will keep the current loop which does two checks. |
mlir/lib/Dialect/SparseTensor/IR/SparseTensorDialect.cpp | ||
---|---|---|
524 | I believe MSVC is unhappy with the signed comparison here. https://lab.llvm.org/buildbot/#/builders/13/builds/26316 C:\buildbot\mlir-x64-windows-ninja\llvm-project\mlir\lib\Dialect\SparseTensor\IR\SparseTensorDialect.cpp(523): error C2220: the following warning is treated as an error C:\buildbot\mlir-x64-windows-ninja\llvm-project\mlir\lib\Dialect\SparseTensor\IR\SparseTensorDialect.cpp(523): warning C4018: '<': signed/unsigned mismatch |
Can you check to see if there's a way to use the SameOperandsShape and SameOperandsElementType traits but restricting them to the memrefs in $xs (rather than for all operands to the op)? If we can, that'd save a lot of code in the verifier. Though last time I checked there wasn't a clean way to do this