Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
mlir/lib/ExecutionEngine/SparseTensorUtils.cpp | ||
---|---|---|
250–262 | remove this big block, the comment goes in too much detail if you want to keep the sizes[r] > 0 assert, put it in loop at L269 | |
261–266 | remove this comment; too much detail and not relevant for the next lines of code | |
433–439 | just revert to original comment all details is in the two new methods addPointer/addIndex if you want to keep some of the notes, I would suggest moving them there, but keeping the comments outside those methods as in the original | |
457–458 | remove comment; that is a good note for future work, but too distracting for reading this block of code | |
539–540 | remove comment |
Please note some build issues, perhaps C++20 issue?
project/mlir/lib/ExecutionEngine/SparseTensorUtils.cpp
/var/lib/buildkite-agent/builds/llvm-project/mlir/lib/ExecutionEngine/SparseTensorUtils.cpp:436:22: error: no member named 'numeric_limits' in namespace 'std'
assert(p <= std::numeric_limits<P>::max() && ~~~~~^
/usr/include/assert.h:93:27: note: expanded from macro 'assert'
(static_cast <bool> (expr) \ ^~~~
mlir/lib/ExecutionEngine/SparseTensorUtils.cpp | ||
---|---|---|
250–262 | I'm fine removing the comment from the code, but I think it should still be documented *somewhere* (since it's nontrivial to deduce what the worst case is and why). Does mlir have any standard practice for where to put such documentation? |
mlir/lib/ExecutionEngine/SparseTensorUtils.cpp | ||
---|---|---|
29 | Ah, that was it ;-) | |
250–262 | In general, the commenting style in this file is concise, so I would adapt to that (as a rule of thumb, mirror the style you find in existing code, if it over communicates, then follow that, if it is terse, keep it that way). For now, I feel the comments go into a lot of detail that are not related to the code where they were placed. Some of these feel like they belong in a design doc. If you feel very strongly about keeping them, move all information to the addPointer() and addIndex() methods. I still prefer conciseness, but would be okay having some of the stuff you have elsewhere at that central place, like the decision to assert on each insertion rather than doing it up front, for instance. |
Yeah, much better. One last nit on the partial loop merging you did
mlir/lib/ExecutionEngine/SparseTensorUtils.cpp | ||
---|---|---|
258–259 | I would remove this comment, we don't have plans for such a subclass, and the printed string on failure already explains what is wrong | |
268 | merging the loops seems unrelated to this change; also if you feel strongly about having one loop, we should also merge L251, and change the comment structure a bit |
removing more comments
mlir/lib/ExecutionEngine/SparseTensorUtils.cpp | ||
---|---|---|
268 | It's less about having a single loop, more that you wanted the assert moved into the loop and I don't see why the assert would be any more closely related to reserving space than the push_back |
Ah, that was it ;-)