This allows operations to control the block ids used by the printer in nested regions.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
mlir/include/mlir/IR/OpAsmInterface.td | ||
---|---|---|
55–56 | The phrasing of this is not the same as others, can you restructure this message to have a bit more detail? and e.g. show an example? | |
mlir/lib/IR/AsmPrinter.cpp | ||
1046–1049 | What's the runtime cost of using std::string for all blocks now? | |
1052 | Please use proper sentences for comments. |
mlir/lib/IR/AsmPrinter.cpp | ||
---|---|---|
1046–1049 | I'd say "not measurable compared to the rest of the infra involved in printing stuff"? The real cost isn't in the block you highlighted actually, it is above: the loop with the while(1) will be invoked when printing the blocks in a function for example. That's an O(N^2) loop in terms of number of blocks... | |
1052 | Except the leading upper case, what's missing? |
mlir/lib/IR/AsmPrinter.cpp | ||
---|---|---|
1046–1049 | (fixed the O(N2) right now)
No, but .... really?
Sure, I'll change the interface to return a callback... |
mlir/lib/IR/AsmPrinter.cpp | ||
---|---|---|
1046–1049 | (Actually that won't change the fact that we'll be using strings instead of unsigned in the map) |
mlir/include/mlir/IR/OpAsmInterface.td | ||
---|---|---|
81 | Why is using std::string necessary? | |
mlir/lib/IR/AsmPrinter.cpp | ||
851 | Values have a separate map for numeric IDs and string names. Why not do the same for blocks? Then it might be possible to avoid some of the penalty for ops that don't implement the interface method. | |
1039–1040 | This looks like an inlined copy of SSANameState::uniqueValueName | |
1041 |
mlir/include/mlir/IR/OpAsmInterface.td | ||
---|---|---|
81 | It is an ownership problem: if you build a string dynamically on the other side of the interface, who owns it? | |
mlir/lib/IR/AsmPrinter.cpp | ||
851 | It just seems overly complex for something that seems extremely unlikely to me to every be a bottleneck anywhere. Note also the tradeoff: here we precompute the string for the ID, while before you recompute a string for the ID on the fly. It's not clear to me that recomputing on the fly the integer serialization is necessarily better. But in any case these are not the bulk of the processing where we're talking about streaming a lot of string to an abstract stream implementation (regardless of the stream destination: string, file, console, socket, ...). | |
1039–1040 | Yes: uniqueValueName has the "SSA value scope" I believe while this is for block names (which don't conflict with SSA value name I believe?). |
mlir/include/mlir/IR/OpAsmInterface.td | ||
---|---|---|
81 | (the alternative would be a "StrAttr" instead I guess?) |
mlir/include/mlir/IR/OpAsmInterface.td | ||
---|---|---|
81 | You mean pass the allocator as an argument? And then return a StringRef? Sure we could do this as well, that seems just overly convolute to me for "block names". |
mlir/include/mlir/IR/OpAsmInterface.td | ||
---|---|---|
81 | I'm okay with std::string, but given that value names have been done a particular way, I find it strange that block names are done in a different way. |
mlir/include/mlir/IR/OpAsmInterface.td | ||
---|---|---|
81 | We can add more indirection and pass a callback to the callback so that the code would call setNameFn like the getAsmResultNames above? | |
81 | (some non-negligible difference I make here is that the number block IDs in a typical IR is a small fraction of the number of SSA values) |
Thanks! Otherwise LGTM
mlir/lib/IR/AsmPrinter.cpp | ||
---|---|---|
2700 | Should this also sort by block name as well as ordering? Named blocks with ordering := -1 might be printed in an unstable order. |
mlir/lib/IR/AsmPrinter.cpp | ||
---|---|---|
1031 | Here we always define an ordering Jeff: even for block that have a name. |
mlir/lib/IR/AsmPrinter.cpp | ||
---|---|---|
1031 | Ah, I missed this. Thanks. |
Rebase.
I don't need this right now, but it is ready to land if we think it is a desirable addition!
I think I would be okay landing this given that it is not super intrusive, and opens up interesting possibilities for users. That being said, I don't have a concrete use in mind right now.
mlir/lib/IR/AsmPrinter.cpp | ||
---|---|---|
984 | Do the other "INVALID" things have an underscore in the name? I can't remember. | |
1025–1029 | We could just say if the explicit name is empty, we use the ordering for a ^bbN name instead. |
The phrasing of this is not the same as others, can you restructure this message to have a bit more detail? and e.g. show an example?