================
@@ -331,9 +335,38 @@ FuncType FuncType::clone(TypeRange inputs, TypeRange
results) const {
return get(llvm::to_vector(inputs), results[0], isVarArg());
}
-mlir::ParseResult parseFuncTypeArgs(mlir::AsmParser &p,
- llvm::SmallVector<mlir::Type> ¶ms,
- bool &isVarArg) {
+// A special parser is needed for function returning void to handle the missing
+// type.
+static mlir::ParseResult parseFuncTypeReturn(mlir::AsmParser &p,
+ mlir::Type &optionalReturnType) {
+ if (succeeded(p.parseOptionalLParen())) {
+ // If we have already a '(', the function has no return type
----------------
keryell wrote:
Yes this is a kind of look-ahead which is required when I introduced to remove
the creation of an artificial `!cir.void` which had the consequence of breaking
an MLIR invariant, `number(return-types) == number(return-values)`.
A C type like `char(int)` is lowered and pretty-printed as
`!cir.func<!cir.int<s, 8>(!cir.int<s, 32>)` while `void(int)` is lowered and
pretty-printed as `!cir.func<(!cir.int<s, 32>)`.
For the MLIR functions themselves, they are handled by the `func` MLIR standard
dialect with a syntax like:
```mlir
func.func @count(%x: i64) -> (i64, i64)
// The same returning nothing:
func.func @f(%x: i64)
```
with an empty type for returning "void".
An alternate design could be to have a new keyword like `void` understood by
the parser to avoid the manual look ahead in the parser as the MLIR default
parser knows how to discriminate with prefix keywords. Then `void(int)` would
be lowered and pretty-printed as `!cir.func<void (!cir.int<s, 32>)`.
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
