[RFC][CIR] Lower cir.bool to i1

[orbiri]

This is an RFC for changing the lowering to LLVM and MLIR to lower cir.bool to i1 all across the board. This dramatically simplifies the lowering logic and the lowered code as it naturally uses i1 for anything boolean.

The change involves separating between type lowering when scalars are involved and when memory is involved. This is a pattern that was inspired by clang's codegen which directly emits i1 from the AST without intermediate higher level representation like CIR has.

This also paves the way to more complex lowerings that are implemented in clang codegen through the three primitives added here: Convert Type For Memory, Emit For Memory and Emit To Memory. They are used in clang for non-trivial types like bitints but also extendible vectors.

A follow up commit to implement the same in DirectLLVM will follow. That commit will properly use the datalayout to lower bool's to memory and thus it is more extensible.

---

One can wonder whether we are missing an upstream core capability of the TypeConvertor which may have been helpful using some type interface to help with these delicate conversions.
P.S.
More elegant solution is to add a dedicated preparation pass to be shared between the pipelines :)

I will work on that instead unless someone thinks otherwise.

[orbiri]

Thinking more about it, I came to realize that it might be more elegant to run a dedicated preparation op pass to lower the memory semantics of cir.bool (and perhaps other types in the future).
That way the “infrastructure” could be shared between DirectLLVM and ThroughMLIR - it will just be a pass that is added to both pipelines!!

[bcardosolopes]

@orbiri overall PR looks good as an initial approach, but as you pointed out, better if the solution can be shared between both pipelines. One natural place for this IMO would be target lowering (where we do CallConv lowering), have you tried looking into doing it at that time and/or find any issues/concerns? I'm suggesting this because it actually feels like ABI, since passing and returning bool is what actually triggers different memory/reg use of bools.

If for some reason it's not a fit there, perhaps a specific pass like you suggested could be a good approach.

[orbiri]

I will have to check, but I’m pretty sure that having bool in a function signature is only possible if you really want a i1 representation (in registers) meaning you are either using bool in C++ or _Bool in modern C. Therefore the pass I may introduce for lowering memory semantics and the change to the lowering are not really related to ABI.

Having said that, as mentioned above - I will first deep dive into the matter and return here with my findings 😇

[orbiri]

@bcardosolopes I took a short tour in the target lowering code. I want to claim that since

1. The only information required to perform the lowering of bool representation in memory is the datalayout (same goes for future types that are handled using the same methods in clang)
2. In clang codegen, these methods are used in same manner - only using datalayout, incorporated in "mainstream" codegen and not in target lowering parts.

then it would be the right choice to separate this concerns here as well.

I will start working on the pass this weekend between the festivities 🦃 , hope to publish something by next one :)

[orbiri]

While trying to create a separate lowering pass, I realized it will require extremely complicated logic and to duplicate almost the entirety of the LLVM/MLIR lowering passes. Few of the reasons van be viewed in the uploaded DirectToLLVM commit:

• Need to convert attributes depending on their type from bool to i8.
• Must handle all pointers to "illegal" types and convert them. This means walking over all operations that may have a pointer as an operand or a value.

In my opinion, implementing this logic in a different pass will create more "spaghetti" then duplicating the logic.

I believe that I'll conclude with outlining the common functions (convertTypeToMemory, emitToMemory, emitFromMemory) and make them cir->cir since the conversion passes will be able to handle this.

---

Of course, still need rebasing and I want to add a couple of more tests, but we are moving forward!