-
Notifications
You must be signed in to change notification settings - Fork 522
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Update C onnx importer #3960
base: main
Are you sure you want to change the base?
Update C onnx importer #3960
Conversation
…Shape special handler
@@ -18,19 +18,29 @@ | |||
// this kind of style. | |||
|
|||
#include "mlir-c/IR.h" | |||
#include "mlir/Support/LLVM.h" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Don't expose LLVM support lib internals as part of the public API.
Looks to be just for FailureOr. Best to find a simpler plain C++ way to do that.
I'd prefer to not introduce the LLVM support into the implementation either. The reason is based on experience: This code will likely end up getting used in a variety of places, some of which will be late binding. The LLVM support library is poorly factored and every time we've used it in "highly traveled" utility code like this, I end up fighting an endless list of ODR violations and other bugs. I don't think it pays for itself when used as part of a standalone library like this. Glancing through the implementation, it is using a few conveniences but most could just be inlined and not introduce the dep. The rest (i.e. ArrayRef, string stuff, etc) have easy alternatives in C++17 and 20. I'd consider using C++20 features for code like this to be a less bad way to go than pulling in the support library for some minor ergonomic stuff.
No description provided.