| commit | 866d77ca87ec97fc8cd48add5649427d6c9265ba | [log] [tgz] |
|---|---|---|
| author | Sandeep Dasgupta <sdasgup@google.com> | Tue Nov 23 06:05:41 2021 +0000 |
| committer | Copybara-Service <copybara-worker@google.com> | Mon Nov 22 22:16:08 2021 -0800 |
| tree | 4fcba11e5f19a4ef5357c20231c56a5a071fbb1d | |
| parent | 10fd5708d4fd586422cd6d924861311e01516361 [diff] |
[mlir] Refactoring a few Parser APIs Refactored two new parser APIs parseGenericOperationAfterOperands and parseCustomOperationName out of parseGenericOperation and parseCustomOperation. Motivation: Sometimes an op can be printed in a special way if certain criteria is met. While parsing, we need to handle all the versions. `parseGenericOperationAfterOperands` is handy in situation where we already parsed the operands and decide to fall back to default parsing. `parseCustomOperationName` is useful when we need to know details (dialect, operation name etc.) about a parsed token meant to be an mlir operation. Reviewed By: rriddle Differential Revision: https://reviews.llvm.org/D113719 GitOrigin-RevId: e5a8c8c883f1f3f91f40c883dd4f613aca0f7105
See https://mlir.llvm.org/ for more information.