Avoiding name clashes from ODSs of different dialects


including ODSs from different dialects can result in name clashes, e.g., defining a pattern mixing operations from std and math:

include "mlir/Dialect/StandardOps/IR/Ops.td"
include "mlir/Dialect/Math/IR/MathOps.td"

// Some Pattern referencing ops from both std and math

results in a name clash for FloatUnaryOp:

/usr/src/llvm-project/mlir/include/mlir/Dialect/Math/IR/MathOps.td:19:7: error: Class ‘FloatUnaryOp’ already defined
class FloatUnaryOp<string mnemonic, list traits = []> :

Is there any way to isolate TableGen classes from ODSs of different dialects?


Tablegen doesn’t have name spaces which is why we normally prefix all operations with the dialect they are in (e.g., TF_AbsOp), seems like this conversion wasn’t followed when math ops were split out from standard (and standard not being prefixed and privileged is another issue). This should be fixed, please file a bug (or send a patch :slight_smile: )



Thanks for the quick feedback. The patch is in D103248.


BTW, Std also contains some unprefixed “intermediate” classes (e.g., ArithmeticBinaryOp). I assume that not only classes directly defining an op, but all classes should be prefixed. Otherwise there might still be clashes for intermediate classes.

I’m happy to send more patches if you think that this is useful!


Sorry forgot to hit reply … Yes indeed it could affect more and prefixing sounds good. We could add a test that just imports all the op td files and verifies that they could co-exist. I need to check if this is mentioned in the ODS doc.