Comments (3)
Recently I'm trying to propose a CIR assembly style guide. Here are some initial drafts that I have worked out so far. Since I just worked the draft out alone based on my biased and limited personal experience, it can be neither comprehensive nor consistent for now, so any suggestions, feedbacks, and discussions are very welcomed and valuable!
RFC: CIR Assembly Style Guide
Naming Convention
The name of a type, an attribute, or an operation should be in snake_case
. Examples:
!cir.int
!cir.long_double<!cir.float>
!cir.data_member
#cir.cmp3way_info
#cir.dyn_cast_info
cir.binop
cir.get_member
The name of a type parameter, an attribute parameter, or an operation argument and result, when defined in TableGen and printed in CIR assembly, should be in snake_case
. (This may be further considered since for now most of these parameters are defined in camelBack
.)
Any keywords that appear in the syntax of a type, an attribute, or an operation, should be in snake_case
.
Assembly Syntax Convention
General Syntax Format
Each operation should follow the following general syntax:
cir.op <args> <regions> `:` <typing> <attr>
Where:
<args>
is the operation’s argument list.<regions>
is any regions introduced by the operation.<typing>
is the operation’s type specifications.<attrs>
is any attributes attached to the operation.
Argument List
The argument list should include all the arguments (except for some attributes as specified in the “placement of attribute” section later) to the operation. Don't use parenthesis around the argument list. The most common format of an argument list is just a comma-separated list:
%3 = cir.libc.memchr %0, %1, %2 : (!cir.ptr<!cir.void>, !s32i, !u64i) -> !cir.ptr<!cir.void>
Beyond that, one can also use auxiliary keywords and some mini-syntaxes in the argument list to make the operation’s assembly more readable:
cir.store %0 to %1 : !s32i, !cir.ptr<!s32i>
%2 = cir.get_runtime_member %0[%1] : (!cir.ptr<!struct>, !cir.data_member<!s32i in !struct>) -> !cir.ptr<!s32i>
Regions
For operations that introduces regions, the regions should follow the argument list in the assembly. One may use auxiliary keywords in the region list to make the assembly more readable:
cir.if %0 {
...
} else {
...
} : !cir.bool
cir.ternary %2 true {
...
cir.yield %0 : !s32i
} false {
...
cir.yield %1 : !s32i
} : !cir.bool -> !s32i
Type Specifications
The type specification gives the types of operation operands and results. Type specifications are placed after the argument list, separated from it with a colon.
If the operation has trait SameOperandsAndResultType
, the type specification should only give a single type that represents the type of operands and results:
%1 = cir.cos %0 : !cir.float
%2 = cir.binop add %0, %1 : !s32i
Otherwise, the type specification can be further split into two type lists separated by a right arrow ( ->
). Before the arrow is a type list for the operands, and after the arrow is a type list for the results. Types in a type list are separated by commas; when a type list includes more than one type, the type list should be surrounded with a parenthesis. If the operation does not have operands or results, the corresponding type list and the right arrow can be omitted.
If the operation has trait SameTypeOperands
, the type list for the operands should only has one type that give the type of the operands:
%2 = cir.ptr_diff %0, %1 : !cir.ptr<!s32i> -> !u64i
Otherwise, the type specification should include a type for each of the operands and the results. Examples:
%2 = cir.get_runtime_member %0[%1] : (!cir.ptr<!struct>, !cir.data_member<!s32i in !struct>) -> !cir.ptr<!s32i>
Placement of Attributes
Attributes on an operation can be classified into the following categories:
- Attributes that affect the semantics of an operation. The operation becomes meaningless or changes semantics without the attribute. For example, a lot of operations take a
kind
attribute that specify which specific operation to perform. These attributes are classified into this category. - Attributes that provide information for further CIR analysis, transformations, and translations, but do not affect the high-level semantics of the operation. AST reference attributes are typical examples in this category.
- All other attributes that do not meet the criterion above.
For attributes in the first category, put them in the argument list. One may place the attribute at any appropriate position within the argument list to make the assembly readable. Example:
%0 = cir.const #cir.int<42> : !s32i
%1 = cir.unary inc %0 : !s32i
%2 = cir.binop add %0, %1 : !s32i
%1 = cir.load %0 volatile : !cir.ptr<!s32i> -> !s32i
%1 = cir.dyn_cast ptrcast %0 : !cir.ptr<!struct> -> !cir.ptr<!cir.void> #cir.dyn_cast_info
For the second category of attributes, put them in the <attrs>
part before any other attributes. Example:
%2 = cir.cmp3way %0, %1 : !s32i -> !u8i #cir.cmp3way<...>
One may use auxiliary keywords when specifying these attributes to make the assembly more readable:
%0 = cir.alloca !s32i init : !cir.ptr<!s32i> name("var")
For the third category of attributes, put them at the end of the <attrs>
part with the attr-dict
TableGen directive.
Unresolved Problems
TODO
from clangir.
Wow, amazing. Can you make this into a PR to gh-pages? So we can do any text suggestions as part of that PR and land it as part of the docs once it's ready?
from clangir.
Can you make this into a PR to gh-pages? So we can do any text suggestions as part of that PR and land it as part of the docs once it's ready?
Opened #619 .
from clangir.
Related Issues (20)
- Should use `getCalleeAttr` when lowering `CallOp`
- 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
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.