Proper support for primitive types

[llvm]

Proper support for primitive types

[felipealmeida]

Hello @bcardosolopes ,

I started hacking ClangIR to test adding bitfields support for ClangIR. I work with specific proprietary instructions that can be very useful with bitfields, however, premature lowering of bitfields accesses to arithmetic/logical instructions makes optimizations very hard to the backend.

However, I looked in other MLIR projects to see how bitfields have been handled and I did not find anything.

Does anyone in the project already have a possible path on how to solve this for ClangIR?

Kind regards,

[xlauko]

How much problematic it'd be for you to drop it when lowering to CIR for now until a concrete use?

I don't mind dropping the qualifiers for now. My main goal at the moment is to see whether VAST -> CIR -> LLVM is a viable path. As we discussed, if there is some common part I am happy to add it to CIR. And this seemed to me as one of them :)

Do you have plans to build an ASTContext from VAST? This could also be necessary in AST-free-CIR, if generating, for instance, LLVM load/store's out of it.

I would need to investigate whether we can reconstruct ASTContext, I don't have answer for that now.

Oh, what kind of problems on high-level-types+attributes you've been running into?

Maybe with newer MLIR version and TypedAttrInterface it is resolved. But the problem we had was with attributes that has vast high-level types, e.g., constants, these can be arbitrarily nested in some non-typed attribute.
And when we tried to lower them from vast types to std types it was not clear if whether and where the attributes contains types that need to be converted.

[bcardosolopes]

@felipealmeida great to hear you played a bit with bitfields.

Does anyone in the project already have a possible path on how to solve this for ClangIR?

Nothing set in stone from our discussions but we surely don't wanna lower them in terms of logical operations right away, but instead proxy it out (and hide the details) over an operation cir.get_bitfield or similar. We can iterate on a design (or a PR) if you already have ideas on how to implement that.

[bcardosolopes]

@felipealmeida Created #13 to track bitfields!

[bcardosolopes]

It might also be worth checking out how polygeist does some of that lowering, could provide interesting insights.

[xlauko]

@bcardosolopes as I am now lowering vast to cir, I might add something similar to vast high-level types to cir:

https://github.com/trailofbits/vast/blob/master/include/vast/Dialect/HighLevel/HighLevelTypes.td

Do you want to retain type qualifiers in cir? Also a tricky part is to define constants with high-level types, they do not cooperate nicely with attributes, and our lowering of their attribute types is a bit hackish at the moment :(

[bcardosolopes]

@bcardosolopes as I am now lowering vast to cir

This is great to hear!

I might add something similar to vast high-level types to cir:

https://github.com/trailofbits/vast/blob/master/include/vast/Dialect/HighLevel/HighLevelTypes.td

Do you want to retain type qualifiers in cir?

This information will be good to have, for sure. The way I was planning to get type qualifiers would be through ASTContext queries on types (which should do the right thing on top of its CanQuals). Type information would come from attached AST nodes, of course that requires AST-capable-CIR to be used. Do you have plans to build an ASTContext from VAST? This could also be necessary in AST-free-CIR, if generating, for instance, LLVM load/store's out of it.

Something like HighLevelTypes.td in CIR would be helpful, specially cause we also want to add something like your CharType, ShortType, etc (purpose of this github issue). How about adding these first and qualifiers as a second step?

Regarding qualifiers, since we don't usually add things without use cases, I'm curious about some pieces:

• Are you planning to (1) write a CIR pass that uses some of this in the shorter term? or (2) something that can concretely provide helpful insight info to codegen? A simple pass that exercises some of this potential would certainly be nice (e.g. produce statistics between number of volatile loads / normals loads, or volatile load/store LLVM codegen pieces).
• How much problematic it'd be for you to drop it when lowering to CIR for now until a concrete use?

Also a tricky part is to define constants with high-level types, they do not cooperate nicely with attributes, and our lowering of their attribute types is a bit hackish at the moment :(

Oh, what kind of problems on high-level-types+attributes you've been running into?

[bcardosolopes]

I don't mind dropping the qualifiers for now. My main goal at the moment is to see whether VAST -> CIR -> LLVM is a viable path.

Sweet, @lanza just started to work on CIR -> LLVM, so I guess we are all going towards the same goal, and adding qualifiers is a big step on that too!

As we discussed, if there is some common part I am happy to add it to CIR. And this seemed to me as one of them :)

Perfect.

Maybe with newer MLIR version and TypedAttrInterface it is resolved. But the problem we had was with attributes that has vast high-level types, e.g., constants, these can be arbitrarily nested in some non-typed attribute. And when we tried to lower them from vast types to std types it was not clear if whether and where the attributes contains types that need to be converted.

Yea, I remember he had to change a lot because of a change past few months ago that decoupled types and attributes, but I'm not sure how much it addresses the problem you are describing :(

[bcardosolopes]

The main parts of this are done, other issues will track further improvements.