diff options
| author | Uday Bondhugula <bondhugula@google.com> | 2018-10-10 13:11:32 -0700 |
|---|---|---|
| committer | jpienaar <jpienaar@google.com> | 2019-03-29 13:27:59 -0700 |
| commit | d05e1f5dd5311debb43eff9434534f775b5fe2c6 (patch) | |
| tree | 2f79070710e27f9bfa8353668c3a8ed559907bcc /mlir/lib | |
| parent | 487cc5061395716465e957803761c572ba5f55e8 (diff) | |
| download | bcm5719-llvm-d05e1f5dd5311debb43eff9434534f775b5fe2c6.tar.gz bcm5719-llvm-d05e1f5dd5311debb43eff9434534f775b5fe2c6.zip | |
Add assert in Operation->printAssembly to check improperly created Op's.
We allow the name of an operation to be different from the name of the
'ConcreteType' op it was instantiated with. This can happen when you sub-class
an existing op and provide a getOperationName for it. Such a situation leads to
an assertion too deep and at a place seeminly unrelated, and typically when the
module is printed with the trace:
printOperation, printAssembly, Op::print, getOperand, dyn_cast<OperationStmt>,
isa. 'isa' will complain about being called on a null pointer, and the null
pointer actually comes from the getAs<> in printAssembly. This should have been
caught in printAssembly.
On another note, it is also weird that we allow setting the op's name to
something independent of the ConcreteType that op was instantiated with - so,
getAs<ConcreteType> will fail since ConcreteType::isClassFor won't succeed on
it.
PiperOrigin-RevId: 216580294
Diffstat (limited to 'mlir/lib')
0 files changed, 0 insertions, 0 deletions
