[CIR] Remove return !cir.void from IR and textual representation #1249
Conversation
|
Hi @keryell, I missed this cause I usually don't go over draft PRs! Does this commit only reverts the original one or does it add anything else on top? I'm a bit confused by the description. |
|
I first reverted the original PR and I am still working on a good solution. |
keryell
force-pushed
the
ronan/remove-void-from-textual-IR
branch
from
aa71766 to
afde518
Compare
|
Can we have a PR that just reverts your previous solution? This might be easier to deal with next time we rebase. Another PR (or this one) can then reintroduce all the work without the MLIR bits? |
Sure. I made #1276 |
|
Landed |
C/C++ functions returning void had an explicit !cir.void return type while not having any returned value, which was breaking a lot of MLIR invariants when the CIR dialect is used in a greater context, for example with the inliner. Now, a C/C++ function returning void has no return type and no return values, which does not break the MLIR invariant about the same number of return types and returned values. This change does not keeps the same parsing/pretty-printed syntax as before for compatibility like in llvm#1203 because it requires some new features from the MLIR parser infrastructure itself, which is not great. For now use a list of return types.
Move from a list of return types with 0 or 1 element to an optional type.
The default MLIR parser for optional parameters requires an optional anchor we do not have in the syntax.
keryell
force-pushed
the
ronan/remove-void-from-textual-IR
branch
from
0b4af61 to
94a19f6
Compare
keryell
changed the title
|
It was more subtle than expected because of MLIR TableGen OptionalParameter current limitations. |
C/C++ functions returning void had an explicit !cir.void return type while not
having any returned value, which was breaking a lot of MLIR invariants when the
CIR dialect is used in a greater context, for example with the inliner.
Now, a C/C++ function returning void has no return type and no return values,
which does not break the MLIR invariant about the same number of return types
and returned values.
This change does not keeps the same parsing/pretty-printed syntax as before for
compatibility like in #1203 because it
requires some new features from the MLIR parser infrastructure itself, which is
not great.
This uses an optional type for function return type.
The default MLIR parser for optional parameters requires an optional anchor we
do not have in the syntax, so use a custom FuncType parser to handle the optional
return type.