Shameless plug for another similar system: http://cwerg.org
Less ambitious with a focus on (measurable) simplicity.
Tilde, My LLVM Alternative
11–20 of 165 posts
Re: Tilde, My LLVM Alternative
#12>I'm calling it Tilde (or TB for tilde backend) and the reasons are pretty simple, i believe it's far too slow at compiling and far too big to be fixed from the inside. It's been 20 years and cruft has built up, time for a "redo". That put a smile on my face because I remember that was how LLVM was born out of frustration with GCC. I dont know how the modern GCC and LLVM compares, I remember LLVM was fast but resulti…
It is pretty much Visual Studion on Windows and XBox, Nintendo and Sony have clang forks.
Embarcadero owns Borland, unfortunely stuff like C++ Builder doesn't seem to get much people outside big corps wanting to use it, which is a shame given its RAD capabilities and GUI design tooling for C++.
Also has a standard ABI between Delphi and C++ Builder, which allows to similar development workflows that .NET offered later with C#/VB alongside Managed C++ extensions (later replaced by C++/CLI).
Re: Tilde, My LLVM Alternative
#13Again, somebody who comes to the realization something is seriously wrong with ultra-complex languages in the SDK (c++ and similar). In other words, since this alternative LLVM is coded in plain and simple C, it is shielded against those who are still not seeing that computer languages with an ultra complex syntax are not the right way to go if if want sane software. You also have QBE, which with cproc will give you…
Cough, C23 and C2y roadmp.
Re: Tilde, My LLVM Alternative
#14I saw Yasser present this at Handmade Seattle in 2023.[0] He explained that when he started working on Tilde, he didn't have any special knowledge or interest in compilers. But he was reading discussions in the Handmade forums, and one of the most popular requests was for an alternative to LLVM, so he thought, "Sure, I'll do that."
Re: Tilde, My LLVM Alternative
#15Good stuff. Hope they succeed. LLVM support for jit:ed and gc:ed languages is pretty weak so a competitor that addresses those and other shortcomings would be welcome.
Re: Tilde, My LLVM Alternative
#16Looking at the commit history inspires some real confidence!
Re: Tilde, My LLVM Alternative
#17Cool. The author has set himself a huge task if he wants to build something like LLVM. An alternative would be to participate in a project with similar goals that is already quite progressed, such as QBE or Eigen ( https://github.com/EigenCompilerSuite/ ) ; both so far lack of optimizers. I consider Eigen very attractive because it supports much more targets and includes assemblers and linkers for all targets. I see…
What’s unfortunate about C++17? It has some nice features that build on C++11’s safety and ergonomic improvements.
Re: Tilde, My LLVM Alternative
#18Shameless plug for another similar system: http://cwerg.org Less ambitious with a focus on (measurable) simplicity.
Cwerg looks interesting indeed. I had it on my radar for some time. Especially its focus on simplicity and independence (e.g. that it can directly generate ELF executables) are attractive. From my humble point of view, both Python 3 and C++17 are a bit unfortunate as implementation languages. I can understand that the author didn't want to use C, but C++98 would have resolved this issue with less build and dependency complexity than C++17. Last year, I intensively evaluated backends and eventually settled on https://github.com/EigenCompilerSuite/, which supports a large number of targets, has a very powerful IR code generator and also comes with its own linkers. Also Eigen is unfortunately written in C++17, but I managed to port all relevant parts to a very moderate C++11 subset (even C++98 seems feasible in future).
Am I wrong to assume that Cwerg doesn't support x86, or is this just assumed by "X86-64"?
Re: Tilde, My LLVM Alternative
#19If you're going to rewrite LLVM, you should avoid just trying to 'do it again but less bloated', because that'll end up where LLVM is now once you've added enough features and optimisation to be competitive.
Rewriting LLVM gives you the opportunity to rethink some of its main problems. Of those I think two big ones include Tablegen and peephole optimisations.
The backend code for LLVM is awful, and tablegen only partially addresses the problem. Most LLVM code for defining instruction opcodes amounts to multiple huge switch statements that stuff every opcode into them, its disgusting. This code is begging for a more elegant solution, I think a functional approach would solve a lot of the problems.
The peephole optimisation in the InstCombime pass is a huge collection of handwritten rules that's been accumulated over time. You probably don't want to try and redo this yourself but it will also be a big barrier to achieving competitive optimisation. You could try and solve the problem by using a superoprimisation approach from the beginning. Look into the Souper paper which automatically generates peepholes for LLVM: (https://github.com/google/souper, https://arxiv.org/pdf/1711.04422.pdf).
Lastly as I hate C++ I have to throw in an obligatory suggestion to rewrite using Rust :p
Re: Tilde, My LLVM Alternative
#20Again, somebody who comes to the realization something is seriously wrong with ultra-complex languages in the SDK (c++ and similar). In other words, since this alternative LLVM is coded in plain and simple C, it is shielded against those who are still not seeing that computer languages with an ultra complex syntax are not the right way to go if if want sane software. You also have QBE, which with cproc will give you…
Cough, C23 and C2y roadmp.
We are fortunately free to ignore "C23 and C2y" and stick with C89 (with the common extensions) or C99.