[Mlir-commits] [mlir] [mlir][AsmPrinter] Print op properties directly in generic form (PR #106996)
Andrei Golubev
llvmlistbot at llvm.org
Tue Sep 3 02:48:43 PDT 2024
andrey-golubev wrote:
> Why is « default constructed » important here?
Never mind, just me explaining the thing poorly. What i meant is: at the point of printing, properties are already constructed one way or another, so printing them "unconditionally" should be possible. For a property of type `T`, I think it is reasonable to require this to succeed: `T some{/* maybe some initializer*/}; some.print();` as the basic case (see [this place](https://github.com/llvm/llvm-project/blob/377045ece6471a1e59bb5239707aad54ba035ff2/mlir/lib/IR/AsmPrinter.cpp#L1942) for where it is important). So we don't really need to convert to attributes from the standpoint of C++ (and MLIR?).
> One thing that has been in mind though, why not change properties to just preserve the string form the same way we do for UnknownAttr/UnknownType when the op isn't registered?
Could you elaborate? I think I'm out of context here. Is the main problem in *parsing*? I.e. if we end up having unregistered operation, we go through [UnregisteredOpModel](https://github.com/llvm/llvm-project/blob/fe1a1eee2ff864d2ba00ad67e6360b7178e67d5c/mlir/include/mlir/IR/OperationSupport.h#L194) and that one has to store properties in some form (now, as a dict attr I guess) until we load all the necessary info and are able to "restore" concrete C++ objects (aka properties)? If you could point me to the places of interest in code, it would be nice, maybe that way I'd have a better idea (or maybe there are tests).
https://github.com/llvm/llvm-project/pull/106996
More information about the Mlir-commits
mailing list