================
@@ -273,29 +273,36 @@ def CIR_PointerType : CIR_Type<"Pointer", "ptr",
def CIR_FuncType : CIR_Type<"Func", "func"> {
let summary = "CIR function type";
let description = [{
- The `!cir.func` is a function type. It consists of a single return type, a
- list of parameter types and can optionally be variadic.
+ The `!cir.func` is a function type. It consists of an optional return type,
+ a list of parameter types and can optionally be variadic.
Example:
```mlir
+ !cir.func<()>
!cir.func<!bool ()>
+ !cir.func<(!s8i, !s8i)>
!cir.func<!s32i (!s8i, !s8i)>
!cir.func<!s32i (!s32i, ...)>
```
}];
let parameters = (ins ArrayRefParameter<"mlir::Type">:$inputs,
- "mlir::Type":$returnType, "bool":$varArg);
+ "mlir::Type":$optionalReturnType, "bool":$varArg);
+ // Use a custom parser to handle the optional return and argument types
+ // without an optional anchor.
let assemblyFormat = [{
- `<` $returnType ` ` `(` custom<FuncTypeArgs>($inputs, $varArg) `>`
+ `<` custom<FuncType>($optionalReturnType, $inputs, $varArg) `>`
}];
let builders = [
+ // Construct with an actual return type or explicit !cir.void
----------------
keryell wrote:
No, I really meant explicit here.
If you put an explicit `!cir.void` in the assembly text, it will be discarded
and will be nowhere in the IR.
It is as if there was
This is for compatibility with pas ClangIR behavior.
Of course, since we are up-streaming it, do we need this backward
compatibility? If not, it might breaks more stuff while rebasing ClangIR
downstream... :thinking:
https://github.com/llvm/llvm-project/pull/128089
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
