`getDefaultDialect` and the `std` dialect

I have a dialect (iree_pydm) which defines func op. Since the dialect is mostly self contained, I use the new getDefaultDialect() feature with it to make it more readable – and it is quite nice.

However, there is some incidental use of the std dialect, specifically for CFG primitives, and this is fine (my dialect bridges types properly). However, my dialect has a select op, and so does the standard dialect. Some CFG patterns produce an std.select on canonicalization but this just prints as select without a prefix. This then fails to round-trip because the parser thinks it is part of my dialect, and it fails verification (mine does not take an i1 condition value).

I’m poking through trying to refresh my memory on how all of this works, but figured I would ask: is there something that makes std special so that its prefixes don’t print?

Yes, std is hardcoded in the parser/printer and “privileged” from this point of view. The only reason I haven’t remove this yet is the churn associated and the fact that I knew we were about to move more things out of it. I’ll happily remove this after the move to arith is done. In the meantime mixing the getDefaultDialect() with std op is broken.

That said, seems like there is an easy fix for the particular bug here: we should be able to not omit the std. prefix when the default dialect is set to something else than builtin.

Thanks, Mehdi - that’s what I was thinking and hunting around for. But I got lost in template goo and thought I’d ask. If you can point me to where it is, I might be able to fix it. Also wouldn’t say no if you did it :slight_smile:

https://reviews.llvm.org/D111204 should fix it!

1 Like