Dropping dialect prefix for ops with multiple dots in the name

MLIR
1

We have an readability-related mechanism in the op parser that lets the op declare the default dialect for the ops contained in its regions. When set up, it makes

foo.bar {
  qux
}

and

foo.bar {
  foo.qux
}

parse to the same IR. The former form is always printed. However, this is broken if the op has dots in its name:

foo.bar {
  baz.qux
}

will be parsed as the qux op from the baz dialect, and fail if there is no such dialect instead of attempting to look up the baz.qux op in the default dialect. The bigger problem is the broken roundtripping where:

foo.bar {
  foo.baz.qux
}

is parsed okay but printed without the leading foo, which cannot be parsed back, or is parsed as a different op.

There are two ways to fix this:

  1. fall back to the default dialect specified by the op for ops that come from unregistered dialects;
  2. ignore the default dialect when printing the op with dots in the name.

Any preference for one or another?

2 Likes
2

If there is a default dialect and an operation has multiple dots, I’d always use the full name. It avoids any kind of ambiguity that would otherwise popup.

– River

1 Like
3

I think that option 2 is the only “safe” one in terms of ambiguity. Otherwise printing an operation foo.bar.baz as bar.baz could conflict with a dialect bar having an op baz that would be registered but not loaded.

1 Like