[CIR] Remove the !cir.void return type for functions returning void

[keryell]

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 not 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 keeps the same parsing/pretty-printed syntax as before for compatibility.

[keryell]

The last failure was masked by the usual noise of 18 failures on my laptop:

Failed Tests (18):
  Clang :: CIR/CodeGen/bf16-ops.c
  Clang :: CIR/CodeGen/builtin-constant-fold.c
  Clang :: CIR/CodeGen/complex-arithmetic.c
  Clang :: CIR/CodeGen/complex-cast.c
  Clang :: CIR/CodeGen/complex.c
  Clang :: CIR/CodeGen/float16-ops.c
  Clang :: CIR/CodeGen/fp16-ops.c
  Clang :: CIR/CodeGen/global-constant.c
  Clang :: CIR/CodeGen/int128.cpp
  Clang :: CIR/CodeGen/static-vars.cpp
  Clang :: CIR/CodeGen/types-IEEE-quad.c
  Clang :: CIR/CodeGen/vectype-ext.cpp
  Clang :: CIR/Lowering/expect.cir
  Clang :: CIR/Lowering/globals.cir
  Clang :: CIR/Lowering/unary-inc-dec.cir
  Clang :: CIR/Lowering/unary-not.cir
  Clang :: CIR/Lowering/vectype.cpp
  Clang :: CIR/mlirprint.c

with -DCMAKE_BUILD_TYPE=Debug -DLLVM_ENABLE_ASSERTIONS=ON. Is this something anyone else has?

[smeenai]

What failure messages do you see, and what platform are you on? I run all tests on Linux with that configuration regularly without issues (using Clang as my host compiler).

[keryell]

What failure messages do you see, and what platform are you on? I run all tests on Linux with that configuration regularly without issues (using Clang as my host compiler).

Ubuntu 24.10 g++14.2 & its C++ lib, Clang20 of the day.

cmake -GNinja \
 -DCLANG_ENABLE_CIR=ON \
 -DCMAKE_BUILD_TYPE=Debug \
 -DCMAKE_C_COMPILER=clang \
 -DCMAKE_CXX_COMPILER=clang++ \
 -DCMAKE_EXPORT_COMPILE_COMMANDS=ON \
  -DLLVM_BUILD_EXAMPLES=ON \
 -DLLVM_BUILD_LLVM_DYLIB=ON \
 -DLLVM_BUILD_UTILS=ON \
 -DLLVM_ENABLE_ASSERTIONS=ON \
 -DMLIR_ENABLE_BINDINGS_PYTHON=ON \
 -DLLVM_ENABLE_PROJECTS="clang;lld;mlir" \
 -DLLVM_ENABLE_RTTI=ON \
 -DLLVM_INSTALL_UTILS=ON \
 -DLLVM_LINK_LLVM_DYLIB=ON \
 -DLLVM_PARALLEL_LINK_JOBS=8 \
 -DLLVM_TARGETS_TO_BUILD:STRING="X86;ARM;AArch64" \
 -DLLVM_USE_LINKER=lld \
 -DPython3_FIND_VIRTUALENV=ONLY \
  -B ... -S ...

[keryell]

A reason is probably that at Meta you use an old lib C++ without the latest cute new floating-point formats.

[smeenai]

Ah, I've seen those before, and they're caused by LLVM_LINK_LLVM_DYLIB, which implies CLANG_LINK_CLANG_DYLIB. It's easy to end up linking LLVM both statically and dynamically, which causes the problems. I'd locally gotten it to work with smeenai@266f602; if that works for you I can put up a PR for it.

The setup still seems kinda fragile overall though, and I ended up switching to BUILD_SHARED_LIBS instead, which worked as-is. I was worried about startup time as a result of all the SOs, but it ended up being good enough for me (especially for a debug build). Is that a potential option for you?

[keryell]

Ah, I've seen those before, and they're caused by LLVM_LINK_LLVM_DYLIB, which implies CLANG_LINK_CLANG_DYLIB. It's easy to end up linking LLVM both statically and dynamically, which causes the problems. I'd locally gotten it to work with smeenai@266f602; if that works for you I can put up a PR for it.

Amazing, I cherry-picked this and it solved my issues!!! 🤯 All the tests are passing now. Go for it. 🚀

The setup still seems kinda fragile overall though, and I ended up switching to BUILD_SHARED_LIBS instead, which worked as-is. I was worried about startup time as a result of all the SOs, but it ended up being good enough for me (especially for a debug build). Is that a potential option for you?

I have no opinion on this. I probably picked these options because of our downstream projects using Clang/LLVM/MLIR libraries.
At the end I want to avoid a bloatware explosion with huge binaries in debug mode with all the libraries copied into each binary.
Guidance welcome. 😄

[smeenai]

Ah, I've seen those before, and they're caused by LLVM_LINK_LLVM_DYLIB, which implies CLANG_LINK_CLANG_DYLIB. It's easy to end up linking LLVM both statically and dynamically, which causes the problems. I'd locally gotten it to work with smeenai@266f602; if that works for you I can put up a PR for it.

Amazing, I cherry-picked this and it solved my issues!!! 🤯 All the tests are passing now. Go for it. 🚀

The setup still seems kinda fragile overall though, and I ended up switching to BUILD_SHARED_LIBS instead, which worked as-is. I was worried about startup time as a result of all the SOs, but it ended up being good enough for me (especially for a debug build). Is that a potential option for you?

I have no opinion on this. I probably picked these options because of our downstream projects using Clang/LLVM/MLIR libraries. At the end I want to avoid a bloatware explosion with huge binaries in debug mode with all the libraries copied into each binary. Guidance welcome. 😄

I put up #1222. I'd recommend trying out BUILD_SHARED_LIBS instead though (and probably tweaking your linker flags to include -Bsymbolic-functions). It'll end up being smaller because MLIR doesn't support LLVM_LINK_LLVM_DYLIB super well, and at least for me the binary load times were pretty acceptable.

[keryell]

@lanza @bcardosolopes Any feedback about this?

[bcardosolopes]

@keryell just landed #1222, let me review the actual PR.

[bcardosolopes]

Thanks for taking the extra length and making the parser flexible enough to support multiple ways to deal with void, yay!

[keryell]

@bcardosolopes Related to the discussion in llvm/llvm-project#120484 (comment), this PR was about fixing the MLIR invariant while keeping exactly the same text representation. It showed that it works and makes some basic MLIR transformations to work.
The final solution, which was a lower priority for me, is to change the textual representation to follow the normal way functions are represented in MLIR rather than displaying a !void for the return type to look more like C/C++. At the end this is an IR, so we do not really care that much and this would not require some new features in MLIR parser infrastructure. But the impact will be massive on the tests with all the -> !void and its alias to be removed.
Since now the function type part is being up-streamed, this second phase has the priority increased and needs to be solved or we up-stream the generation of invalid MLIR IR as before this PR.