This is an archive of the discontinued LLVM Phabricator instance.

[mlir][sparse] Improve `DimLvlMapParser`'s handling of variable bindings
ClosedPublic

Authored by wrengr on Jul 17 2023, 6:05 PM.

Details

Summary

This commit comprises a number of related changes:

(1) Reintroduces the semantic distinction between parseVarUsage vs parseVarBinding, adds documentation explaining the distinction, and adds commentary to the one place that violates the desired/intended semantics.

(2) Improves documentation/commentary about the forward-declaration of level-vars, and about the meaning of the bool parameter to parseLvlSpec.

(2) Removes the VarEnv::addVars method, and instead has DimLvlMapParser handle the conversion issues directly. In particular, the parser now stores and maintains the {dims,lvls}AndSymbols arrays, thereby avoiding the O(n^2) behavior of scanning through the entire VarEnv for each parse{Dim,Lvl}Spec call. Unfortunately there still remains another source of O(n^2) behavior, namely: the AsmParser::parseAffineExpr method will copy the DimLvlMapParser::{dims,lvls}AndSymbols arrays into AffineParser::dimsAndSymbols on each parse{Dim,Lvl}Spec call; but fixing that would require extensive changes to AffineParser itself.

Depends On D155532

Diff Detail

Event Timeline

wrengr created this revision.Jul 17 2023, 6:05 PM
Herald added a project: Restricted Project. · View Herald TranscriptJul 17 2023, 6:05 PM
wrengr requested review of this revision.Jul 17 2023, 6:05 PM
wrengr updated this revision to Diff 541290.Jul 17 2023, 6:08 PM

git-clang-format

wrengr edited the summary of this revision. (Show Details)Jul 19 2023, 12:25 PM
wrengr updated this revision to Diff 542161.Jul 19 2023, 12:53 PM

Adding tests for three error conditions where the lvl-var forward-decls don't match the lvl-var bindings in the lvl-specs

Peiming added inline comments.Jul 19 2023, 2:00 PM
mlir/lib/Dialect/SparseTensor/IR/Detail/DimLvlMapParser.cpp
97–98

Is the variable ever used after returning from parseVar?

262–282

support*s*?

328–334

If so, what not just renaming the two function into parseVar and parseAndBindVar to make the name more self-explainable ?

wrengr updated this revision to Diff 542248.Jul 19 2023, 4:56 PM
wrengr marked 3 inline comments as done.

Fixed typo. Added assertions re the didCreate out-parameter of parseVar.

mlir/lib/Dialect/SparseTensor/IR/Detail/DimLvlMapParser.cpp
97–98

Nope, it's only declared because it's needed for the out-parameter. Once requireKnown is fixed, whenever parseVar returns successfully then we can deduce what didCreate must be. I'll add some assertions just to make that more explicit.

In other/older versions of the code, I returned the bool along with the id, since there were callsites that wanted that information. In this latest version of the code, I seem to have gotten rid of all the places that needed that information. My plan is to leave the out-parameter there for now, in case any new callsites crop up; and once the parser is more mature, then we can get rid of it if it's still unneeded.

262–282

good catch

328–334

The parseVar{Usage,Binding} methods are intended to be the "internally-public API"; whereas parseVar is "internally-private" and is only defined in order to avoid code duplication between parseVar{Usage,Binding}. The "binding"/"use" distinction is a very salient and semantically well-defined distinction across languages; and after writing numerous parsers for syntaxes with variable-bindings, I've seen that making the distinction goes a long way toward keeping code clean and avoiding bugs.

The fact that we abuse parseVarUsage here is just part of the forward-declaration workaround; and that workaround is something we want to get rid of in the long run. Therefore, I think it's much better to simply document the abuse, rather than twisting up the whole API.

Peiming accepted this revision.Jul 19 2023, 7:42 PM
This revision is now accepted and ready to land.Jul 19 2023, 7:42 PM