I have a use case where I would like to create an op if the parameters I have are suitable for creating that op. If the parameters are not suitable, then I will not create that op, but I will print a warning regarding the fact that the op was not created and why it was not created.
Currently, I have code that checks the given parameters and returns a LogicalResult to indicate if they are suitable, and also fills a string with the reason that they aren’t valid if that is the case.
This works fine, but the op in question is defined in a .td file with various constraints. All the constraints defined in the .td file are translated to autogenerated code which is called during verify.
This means that in essence, the constraints regarding the op are written twice. Once in the check code I wrote, and once in the autogenerated code based on definitions from the .td file.
This seems like wasteful and error prone code duplication.
So, instead if duplicating the autogenerated checks, I thought about first creating the op and calling the verify method and deleting the op if the result is failure.
The problem with that approach is that any problems with the parameters will be printed as errors and not as warnings, and in addition I was worried about encountering any asserts in the verify code that will cause a crash when running in debug mode.
Has anyone had a similar use case and can share how it was handled?
1 Like
I believe this RFC was proposed to solve this problem but I don’t think any patches have landed. For the approach of calling verify directly, you can register a diagnostics handler to capture any diagnostics just around that logic that creates the op and calls verify. You just have to make sure your custom verifier function doesn’t have any asserts. The autogenerated invariants verification code won’t have any asserts. But I’d be interested to hear how others tackle this problem.
1 Like