[Backend] C language source to source backend

[archibate]

Concisely describe the proposed feature
Currently we have LLVM serve as a CPU backend, but LLVM is highly complicated and needs to be installed carefully, so that compiled Taichi program cannot run on a environment without a good environment support. e.g.

1. A 32-bit machine.
2. Cannot make python version happy anyway.
3. Cannot make LLVM happy like [Bug] [OpenGL] with_opengl crashed with segfault after upgrading #1325.
4. A headless server without X11 support therefore GLFW can't make a valid context).
5. For advanced optimization, compile-time may take too long for some huge programs, it would be great if we could store the pre-compile result in C source/object for Taichi applications to start up faster.

So, I would like to add a C language source to source backend, i.e. translate Taichi IR into C plain source code, which is aimed to be:

1. Easy to copy-and-paste.
2. Pure, computation only, not rely on any complicated library.
3. C99 portable, runs on any machine, any C compiler.
4. Can easily export result to file, so that anyone without Taichi could run the code.
5. Could also implement a pure JavaScript one for building Web shaders using Taichi?

Describe the solution you'd like (if any)
Follow up the source to source attempt/infrastructure in OpenGL and Metal.
For the ti.export, since currently Taichi is made in a JIT manner, some refactor may be done to make it only compile but not execute.

Additional comments
Feel free to close me without a reason if you feel this useless.

[yuanming-hu]

I think it's a great idea!

If you are interested in doing this, please feel free to ahead and do it. We don't need to support sparse data structures for the C backend, at least in the beginning.

Once we have a C backend, we can use Emscripten to compile C to Javascript, resulting in a Javascript backend.

[Luohaothu]

Great idea! We can finally use Taichi as interpreter now😂

BTW, will the generated code run on GPU or CPU only? And will SIMD be re-supported?

[archibate]

SIMD

No, for now, after a private talk with @yuanming-hu , having these complex features like multithreading and SIMD in C backend is technically possible, but may cause compat issues. e.g. if people want to use Emscripten to translate generated C into JS.
So we will keep the C backend portable and educational.
But @yuanming-hu promise that we will re-support SIMD on LLVM CPU backend at some point.

[yuanming-hu]

Yeah, SIMD will be recovered in the future, for LLVM backends (x64, ARM64) - not sure when we will have the energy to do that.

[Luohaothu]

I've been reading the legacy code recently, and it appears to me that the part for SIMD is the SLPVectorize IRVisitor. So I wonder if this is the whole picture or there are other issues needed to be taken care of (in the case of LLVM backends)?

[yuanming-hu]

We don't plan to do SLPVectorize any more. LoopVectorize is all we need, but it's been unmaintained for too long, and there are many places in the current code base that do assume we don't vertorize at all. So it's not an easy task to add CPU vectorization.

Given people who want performance are usually using GPUs nowadays, I think this is not very urgent (but still very helpful for CPU users).

[Luohaothu]

Given people who want performance are usually using GPUs nowadays, I think this is not very urgent (but still very helpful for CPU users).

Indeed...Still have to write some tough code for our cluster users 😂

[samuela]

Forgive me if I'm misunderstanding something, but why is this advantageous vs LLVM? Shouldn't LLVM be able to build 32-bit binaries? And compile to emscripten, etc?

[archibate]

Forgive me if I'm misunderstanding something, but why is this advantageous vs LLVM? Shouldn't LLVM be able to build 32-bit binaries? And compile to emscripten, etc?

1. Currently the LLVM backend of Taichi is only available in 64-bit.
2. @yuanming-hu, the author of LLVM backend, doesn't have much time on this.
3. Generating a C source file (C99 standard) is more portable, easy to embed into other C/C++ projects.
4. The LLVM backend supports multi-threading, which could make Emscripten (whose output runs on browser) fail to work IMO.