Comments (8)
The
mlir::IntegerType
can track the width of an integer as well as if it is singed/unsigned/signless (See sitio-couto@762cd50).The built-in Floating point types seem to cover all C/C++ primitives as well.
Yeah I now, it's pretty attractive (I've been there).
With this in mind, should we use MLIR's built-in type for C/C++ primitives instead of custom CIR types? I'm not sure how would we benefit from a custom
cir.int
/cir.float
otherwise.
I still believe we should wrap them so we can customize as we see fit (e.g. adding CIR specific attributes that won't be dropped by random passes) and hide the rest of CIR from MLIR in tree changes - example: if they decide at some point that the types should be part of a specific dialect, we only have to change our implementation in one specific place. It will also make our lives easier when adding qualifiers (be it by incorporating clang types with specific attributes or adding our own notion of qualifiers).
from clangir.
I still believe we should wrap them so we can customize as we see fit (e.g. adding CIR specific attributes that won't be dropped by random passes) and hide the rest of CIR from MLIR in tree changes - example: if they decide at some point that the types should be part of a specific dialect, we only have to change our implementation in one specific place. It will also make our lives easier when adding qualifiers (be it by incorporating clang types with specific attributes or adding our own notion of qualifiers).
Yup. As a first-principle we want to avoid being coupled to downstream MLIR changes. Rebasing against MLIR is an absolute nightmare. And when they change functionality of dialects/types/etc we become upwards exposed to surprise behavioral differences. I doubt mlir::IntegerType
is changing much going forward, but AFAIK there's no guarantee that it doesn't.
At a high level, we use MLIR as an infrastructure for writing an IR and not as a tree of dialects that we can use.
It would be fine as an intermediate step if we used mlir
's type, but that just pushes the work forward to some future date.
from clangir.
@bcardosolopes @lanza can you take a look at this draft:
It implements a custom cir.int
type and attribute to partially detach CIR from MLIR's built-in integers and track signedness information.
from clangir.
Yep, that's the status quo, and this is also related with #5
Both are something we're gonna have to tackle sooner than later anyways, in case you wanna add to your list!
from clangir.
@bcardosolopes regarding #5, what is the level of granularity we are looking for?
Does a cir.int
and cir.float
with arbitrary sizes suffice?
Or would a type-per-keyword scheme (cir.char
,cir.short
, ...) be preferable?
I suggest we mirror MLIR's built-in dialect types (single int type with arbitrary size and one float type per size), since it already tracks signedness, then add a few qualifier attributes to mark const
and volatile
types.
from clangir.
Does a
cir.int
andcir.float
with arbitrary sizes suffice? Or would a type-per-keyword scheme (cir.char
,cir.short
, ...) be preferable?
Tracking arbitrary sizes sounds good enough.
I suggest we mirror MLIR's built-in dialect types (single int type with arbitrary size and one float type per size), since it already tracks signedness
Signedness is pretty important because we want code analysis writers to be able to detect things like integer overflows and whatnots. If we can take advantage of the underlying in-tree primitive types to represent that, all we would need is an extra getter method for C/C++ specific signed/unsigned queries.
Implementing primitive types while tracking signedness would be step (1).
Step (2): we should also consider adding an optional clang::Type
or similar (just like we do keep RecordDecl
's around wrapped in an attribute for cir.struct
). It's possible some analysis might wanna check uses of (or lack of) size_t
, which we know it's an alias for a primitive type but we don't wanna create a new type for it.
then add a few qualifier attributes to mark
const
andvolatile
types.
This brings an interesting point, qualifiers in clang are not part of the type, I believe the intent was to optimize memory usage for not creating extra types every time there's a qualifier variation (and also possibly helps to implement deductions that drop qualifiers, etc). We should probably handle qualifiers as part of step (2) or a new step (3), so we have some time to think/discuss while we make progress. Thoughts?
from clangir.
Regarding step 1, using mlir::IntegerType
and mlir::Float
built-in types should suffice.
If we can take advantage of the underlying in-tree primitive types to represent that, all we would need is an extra getter method for C/C++ specific signed/unsigned queries.
The mlir::IntegerType
can track the width of an integer as well as if it is singed/unsigned/signless (See sitio-couto@762cd50).
The built-in Floating point types seem to cover all C/C++ primitives as well.
With this in mind, should we use MLIR's built-in type for C/C++ primitives instead of custom CIR types?
I'm not sure how would we benefit from a custom cir.int
/cir.float
otherwise.
from clangir.
#72 merged
from clangir.
Related Issues (20)
- Should mark private visibility for extern symbols.
- Vector related arith missing `nsw` on addition HOT 2
- Revisit insertion point being restored by an InsertionGuard in `buildSwitchBody()` HOT 1
- [Umbrella] Switch stmt CIRGen issues
- Single-operand vector shuffling HOT 1
- [ThroughMLIR] cir-opt can not work when lowering ForOp to scf HOT 4
- Add a test for arrays of 3-component extended vectors
- Crash with try statement HOT 1
- [GSoC] Add OpenCL support to compile GPU kernels
- Reinstate #668 and #678 HOT 2
- Verify ZdlPv -> ZdlPvm in `test/CIR/CodeGen/dtors.cpp`
- Verify gep uses moving to i64
- Replace uses of `isa`/`dyn_cast`/`cast`/... member functions HOT 2
- Data layout modeling for CIR types
- Add support for `__atomic_thread_fence` HOT 3
- Add canonicalization passes for cir.complex.create
- Problem with emitting MLIR from CIR: `cir.func` gets `dsolocal` attribute HOT 4
- Non-constant memory order in atomic built-ins HOT 3
- Keep higher level abstraction for runtime memory orders on atomics
- `emit-cir-flat` is a bit broken HOT 2
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from clangir.