Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Draft
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

orbiri
Copy link
Collaborator

@orbiri orbiri commented Nov 23, 2024

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
Copy link
Collaborator Author

orbiri commented Nov 23, 2024

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
Copy link
Member

@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
Copy link
Collaborator Author

orbiri commented Nov 25, 2024

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 😇

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants