Soren Lassen

> The change to import OptType looks good. Any idea about adding the code to handle OptType in future PR? Please merge the PR, then I'll rename GetTensorByOnnxName in a...

@chentong319 I believe a different approach is needed for Optional Type because you need to decide at runtime if it's populated or not, so you cannot use None type or...

can we close this issue now that PR #1633 has landed?

thanks for the explanation of DenseResourceElementsAttr, it looks really interesting > resource blobs supports user-defined deleter that will free the underlying data when the data is not used can you...

> Would you mind I put up a PR to delete it? deleting this unused code sounds good to me, please go ahead and submit a PR

I found this LLVM discourse thread where you describe onnx-mlir's solution: https://discourse.llvm.org/t/mlircontext-doesnt-free-denseelementsattributes-and-bloats-memory/3691/24 sharing it here because the thread contains a good discussion that's worth reading

> The special problem with shape inference is that there is a binding for the block arguments and the merging for the joined control flow. Not sure about whether MLIR...

> 5. repeat step 2 until S_arguments reaches fixed point this repeat is done by the loop in `ONNXOpTransformPass::runOnOperation()`, right?

> Can we use inlining provided by MLIR after the function is imported into onnx-mlir? maybe, but I think the protobuf-to-mlir import logic in FrontendDialectTransformer is simplest if we inline...

Note that the lack of polymorphic type/shape system and given the way we lower with fixed shapes means that it will only be practical to share functions between call sites...