[RFC][CIR] Lower cir.bool
to i1
#1158
Draft
+119
−116
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This is an RFC for changing the lowering to LLVM and MLIR to lower
cir.bool
toi1
all across the board. This dramatically simplifies the lowering logic and the lowered code as it naturally usesi1
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
andEmit 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 theTypeConvertor
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.