[Proposal] Merge `mlir::cir` namespace into `cir`

[smeenai]

We currently define the CIR dialect under the mlir::cir namespace, which is a historical leftover from when CIR lived under MLIR instead of Clang (at the very start of the project). We also have a separate cir namespace to hold e.g. our lowering patterns. This is unfortunate, because in many source files you have

using namespace cir;
using namespace mlir;
using namespace mlir::cir;

And then cir:: becomes ambiguous between ::cir and mlir::cir, leading to various errors. You can leave off the using namespace, but typing out mlir::cir::FooOp everywhere is annoying and adds a bunch of noise IMO.

I'm proposing that we merge mlir::cir into cir instead. This matches Flang, which uses the fir namespace for its IR (and the hlfir namespace for its higher-level IR). It's also an easy change to perform mechanically, and cir:: is a small enough prefix that I'm happy to go either way on the using namespace afterwards. (Flang does a mix, but it seems to prefer spelling out fir:: explicitly.)

A small complication is that some names are common between the cir and mlir::cir namespaces, namely ABIInfo, RequiredArgs, and ReturnValueSlot. This is kinda surprising to me, and it seems like a good opportunity to disambiguate them instead of anything that should block the namespace merge.

As a follow-up, these symbols that live in cir have their corresponding symbols live under clang::CodeGen: https://gist.github.com/smeenai/8438fd01588109fcdbde5c8652781dc0. We should also probably move them to a corresponding namespace (e.g. clang::CIRGen) to match the original CodeGen better. That'll be less mechanical though, so I want it to be a separate step from the mlir::cir merging.

Some references, based on a rudimentary analysis of the demangled symbols from a CIR-enabled clang and flang-new:

• Top-level symbols under the cir namespace: https://gist.github.com/smeenai/e6751324254716b673de84cf2533038f
• Top-level symbols under the mlir::cir namespace: https://gist.github.com/smeenai/0a0cf966cb86c9410d9ea98d94d6a7fe
• Top-level symbols under the fir namespace: https://gist.github.com/smeenai/100e4780e48e3966c87c8fd9621a71b4
• Top-level symbols under the clang::CodeGen namespace: https://gist.github.com/smeenai/781d6cd37a95ca7b7f73fa1a3b6774aa

CCing some people who might have opinions on this: @bcardosolopes, @lanza, @dkolsen-pgi, @keryell, @Lancern

[bcardosolopes]

Thanks for putting this together @smeenai, this is a real annoying problem we need to solve.

I'm fine with ::mlir::cir:: becoming ::cir, but I'm confused on how you plan to later tackle to move things from the current ::cir to a said future clang::cirgen if you are merging all of it in ::cir first. Not clear how you'd go about cherry-picking the CIRGen pieces.

I personally thing that the current ::cir is the worse problem here, existing ::mlir::cir doesn't really bother me. So even if they are tackled in different PRs, it might be useful to have a full plan already.

[smeenai]

@bcardosolopes, by my rough analysis, ::cir has 63 symbols that should move into a future ::clang::CIRGen: https://gist.github.com/smeenai/8438fd01588109fcdbde5c8652781dc0. It has 158 symbols in total (https://gist.github.com/smeenai/e6751324254716b673de84cf2533038f), and the remaining ones seem appropriate for the namespace, e.g. the lowering classes. If you think we should split some of those into other namespaces too, I'm happy to do that. All of that splitting will need to be done by hand though (at least partially), so I don't think it makes a difference if we merge ::mlir::cir into ::cir before or after that, since we'd have to find all those symbols and manually move them into the right symbol in either case. Let me know if I misunderstood what you meant though.

One problem though is that we have three symbols duplicated between ::cir and ::mir:cir:

• cir::ABIInfo and mlir::CIR::ABIInfo
• cir::RequiredArgs and mlir::cir::RequiredArgs
• cir::ReturnValueSlot and mlir::cir::ReturnValueSlot

The cir ones are all in clang/lib/CIR/CodeGen, and the mlir::cir ones are all in clang/lib/CIR/Dialect/Transforms/TargetLowering. I assume the duplication is because of build dependency graph issues, e.g. maybe we didn't want TargetLowering to depend on clangCIR? There might also be some differences in how the classes operate, I haven't looked too closely. My initial plan was to just prefix the TargetLowering class names with TargetLowering to disambiguate, unless you feel strongly that we should deduplicate first.

[bcardosolopes]

If you think we should split some of those into other namespaces too

I'm good with only two, my suggestion is to keep all lowercase

Let me know if I misunderstood what you meant though.

I'm just worried that things that were never in mlir::cir may now land/stay in the new ::cir, because you are merging all over there before splitting. But if you are sure this won't happen when doing the manual work, fine by me.

... One problem though is that we have three symbols duplicated

filed another issue to cover that

[smeenai]

If you think we should split some of those into other namespaces too

I'm good with only two, my suggestion is to keep all lowercase

As in clang::cirgen instead of clang::CIRGen? Works for me, I'd only suggested the second one to try to match the existing clang::CodeGen namespace.

Let me know if I misunderstood what you meant though.

I'm just worried that things that were never in mlir::cir may now land/stay in the new ::cir, because you are merging all over there before splitting. But if you are sure this won't happen when doing the manual work, fine by me.

I don't think anything that's not in mlir::cir should end up in ::cir, unless I mess up the change :D The only thing I'm planning to do is take all existing things inside mlir::cir and put then into ::cir (and remove mlir::cir entirely); nothing else should end up in ::cir as a result.

Edit: I think I understand your concern now; it's about future additions to CIRGen ending up in the wrong namespace, not about the current state of the world. That's valid, and I hadn't considered it. I'll see how much work it is to fix the ::cir namespace first then.

[keryell]

Thanks for this great analysis!
Having everything in a single cir:: namespace will avoid the blast effect we have now when using a

#include "clang/CIR/MissingFeatures.h"

I have noticed that we would still have some cir::CIR redundancy in some naming, like cir::CIRGenVTables which almost not present if fir:: and not at all in clang::.
If we remove it with cir::GenVTables it saves 3 letters and it is even more compelling to drop the using namespace cir. 😄
I find using namespace a cognitive burden preventing inclusion of new people or people context-switching between different projects.

[bcardosolopes]

As in clang::cirgen instead of clang::CIRGen? Works for me, I'd only suggested the second one to try to match the existing clang::CodeGen namespace.

I kinda feel like in the end this is potential bikeshed for upstreaming, so probably my opinion doesn't matter as much hehe!

[smeenai]

Thanks for this great analysis! Having everything in a single cir:: namespace will avoid the blast effect we have now when using a

#include "clang/CIR/MissingFeatures.h"

I have noticed that we would still have some cir::CIR redundancy in some naming, like cir::CIRGenVTables which almost not present if fir:: and not at all in clang::. If we remove it with cir::GenVTables it saves 3 letters and it is even more compelling to drop the using namespace cir. 😄 I find using namespace a cognitive burden preventing inclusion of new people or people context-switching between different projects.

I agree with you about the redundancy and removing all temptation for using namespace :) There's also the standard tension of how much we want to match original CodeGen though, e.g. it has clang::CodeGen::CodeGenVTables, which the CIRGen prefix (and potential future clang::CIRGen sub-namespace) are trying to match.