This function simplifies calling the getChecked methods on Attributes and Types from within the parser, and removes any need to use getEncodedSourceLocation for these methods (by using an SMLoc instead). This is much more efficient than using an mlir::Location, as the encoding process to produce an mlir::Location is inefficient and undesirable for parsing (locations used during parsing should not persist afterwards unless otherwise necessary).
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
mlir/include/mlir/IR/DialectImplementation.h | ||
---|---|---|
175 | SMLoc is a very specific to textual IR format parsing (debug/test format) part of the world. Does it make as much sense in IR? Is there an alternative where Location is cheap to create from SMLoc for just these parsing cases where we know the context outlives the potential use? (Alternatively this as a helper method in utils that just makes the getChecked inside smaller to write at call site?). SMLoc just feels a bit weird here. |
mlir/include/mlir/IR/DialectImplementation.h | ||
---|---|---|
175 | I'm not sure what you are getting at. This is the parser for attributes and types, this almost exclusively uses llvm::SMLoc. I don't see any other location format being useful here, this class is only used for textual IR format parsing. |
Nice improvement, thanks
mlir/include/mlir/IR/DialectImplementation.h | ||
---|---|---|
175 | Yeah I was in wrong file "in my mind" switching tabs and I just looked at the snippets. |
SMLoc is a very specific to textual IR format parsing (debug/test format) part of the world. Does it make as much sense in IR? Is there an alternative where Location is cheap to create from SMLoc for just these parsing cases where we know the context outlives the potential use? (Alternatively this as a helper method in utils that just makes the getChecked inside smaller to write at call site?). SMLoc just feels a bit weird here.