12 ms·

Tilde, My LLVM Alternative

361 points by davikr 2y ago

IshKebab 2y ago
I dunno if "twice as fast as Clang" is very impressive. How fast is it compared to Clang 1.0? Also starting a new project like this in C is an interesting choice.
- oguz-ismail 2y ago
  > interesting choice No serious alternative
  - IshKebab 2y ago
    Rust? Zig?
    - oguz-ismail 2y ago
      [flagged]
      - IshKebab 2y ago
        Ah yes, the 10th most popular general purpose programming language in the world is a meme language. Facepalm. I know you'll ask for a source on that so: https://www.jetbrains.com/lp/devecosystem-2024/ https://www.jetbrains.com/lp/devecosystem-2024/ Excluding HTML, CSS, Shell and SQL because they aren't general purpose programming languages. Excluding Typescript because it's really just type annotations for JavaScript.
        oguz-ismail 2y ago
        > Based on the responses from 23,262 developers worldwide, Yeah
    - lerno 2y ago
      No, just no
  - twic 2y ago
    Compilation is high-level work, so you could do it in any high-level language.
Rochus 2y ago
Cool. 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/ 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 the advantage in having a C implementation; Eigen is unfortunately developed in C++17, but I managed to backport the parts I'm using to a moderate C++11 subset (https://github.com/rochus-keller/Eigen https://github.com/rochus-keller/Eigen). There are different front-ends available, two C compilers among them. And - as mentioned - an optimizer would be great. EDIT: just found this podcast where the author gives more informations about the project goals and history (at least the beginning of the podcast is interesting): https://www.youtube.com/watch?v=f2khyLEc-Hw https://www.youtube.com/watch?v=f2khyLEc-Hw
- wffurr 2y ago
  What’s unfortunate about C++17? It has some nice features that build on C++11’s safety and ergonomic improvements.
  - Rochus 2y ago
    You need a large, modern C++ compiler and standard library, which are not available for most older systems, and you're inviting an excess of dependencies because not all compilers support all parts of the newer C++ standards (in the same way), and require a lot more resources and newer versions of APIs and libraries, which further limits their usability on older systems. Furthermore, C89 and C++98 are much easier to bootstrap than a colossus like LLVM and Clang. The few "nice features" are perhaps enticing, but the costs they incur are disproportionate.
  - o11c 2y ago
    For reference, GCC 4.7 (released March 2012) was the last build of GCC that is written in C, and supports almost all of the C++11 language (4.8.1, written in C++, finished the last bits) and a fair amount of the library. If you have to work on a system that hasn't been updated since 2014 or so (since it's fair enough to avoid the .0 releases), getting support for later C++ standards is significantly more complicated.
s3graham 2y ago
This looks pretty cool. I've been looking at all the "small" backends recently. It's so much nicer to work with one of them than trying to wrangle LLVM. QBE, MIR, & IR (php's) are all worth a look too. Personally I've settled on IR for now because it seemed to match my needs the most closely. It's actively developed, has aarch64 in addition to x64 (looks like TB has just started that?), does x64 Windows ABI, and seems to generate decent code quickly.
mungaihaha 2y ago
> I believe it's (LLVM) far too slow at compiling and far too big to be fixed from the inside What are you doing to make sure Tilde does not end up like this?
- fermigier 2y ago
  "You either die a hero or live long enough to see yourself become the villain".
  - Ygg2 2y ago
    You either reinvent the wheel but square or live long enough to make it a circle.
- snowfarthing 2y ago
  I just had a random thought: perhaps it would be a good idea to have a project that doesn't do optimizations, but just focuses on fast compiling. Then again, I now can't help but wonder if LLVM (or even GCC) would be fast, if you just turned off all the optimizations ... (Of course, at this point, I can't help but think "you don't need to worry about the speed of compilation" in things like Common Lisp or Smalltalk, because everything is compiled incrementally and immediately, so you don't have to wait for the entire project to compile before you could test something ...)
  - ajross 2y ago
    > Then again, I now can't help but wonder if LLVM (or even GCC) would be fast, if you just turned off all the optimizations ... It's not the optimizations really, it's the language front ends. Rust and C++ are extremely analysis-heavy. Try generating a comparable binary in C (or a kernel build, which is likely to be much larger!) and see how fast these compilers can be.
  - christophilus 2y ago
    Go’s internal compiler / linker is kind of like that. So is qbe[0] iirc. https://c9x.me/compile/ https://c9x.me/compile/
melodyogonna 2y ago
Chris Lattner seems to have also created an alternative for LLVM - https://mlir.llvm.org/ https://mlir.llvm.org/ Because of how the architecture works, LLVM is one of the backends, but it doesn't have to be. Very interesting project, you could do a lot more IR processing before descending to LLVM (if you use that), that way you could give LLVM a lot less to do. Chris has said LLVM is fast at what it is designed to do - lower IR to machine code. However, because of how convoluted it can get, and the difficulty involved in getting information from some language-specific MIR to LLVM, languages are forced to generate tons upon tons of IR so as to capture every possible detail. Then LLVM is asked to clean up and optimize this IR. One thing to look out for is the problem of either losing language-specific information when moving from MIR to Low-level IR (be it Tilde or LLVM) or generating too much information, most of it useless.
- _flux 2y ago
  I wonder if one solution would be have tighter integration between the layers, so the backend could ask for some IR to be generated? Basically starting from the program entrypoints. This way the frontend wouldn't need to generate all the possible code up-front. Mind you, I've never written a compiler after that Uni course and touched LLVM IR a long time ago
  - melodyogonna 2y ago
    That is how MLIR works. Basically you have multiple levels of IR, you can optimize each level until you get to the last level. It also has the advantage of being able to parallelize passes
- zellyn 2y ago
  I wonder if this question can attract any MLIR people to answer my question: From Chris Lattner's descriptions of LLVM vs MLIR in various podcasts, it seems like LLVM is often used as a backend for MLIR, but only because so much work has been put into optimizing in LLVM. It also seems like MLIR is strictly a superset of LLVM in terms of capabilities. Here's my question: It seems inevitable that people will eventually port all LLVM's smarts directly into MLIR, and remove the need to shift between the two. Is that right?
ksec 2y ago
>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 resulting binary were not as optimised, once those optimisation added it became slower. While LLVM was a wake up call to modernise GCC and make it faster. In the end competition made both a lot better. I believe some industry ( Gaming ) used to swear by VS Studio / MS Compiler / Intel Compiler or languages that depends / prefer the Borland ( What ever they are called now ) compiler. Its been very long since I last looked I am wondering if those two are still used or have we all merged mostly into LLVM / GCC?
- pjmlp 2y ago
  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).
  - deleted 2y ago
    [deleted]
  - s1gsegv 2y ago
    Borland as of a few years ago also ships a clang fork for C++ Builder, interestingly enough. It unfortunately does not solve all of the problems you encounter using C++ Builder in the modern age. I’ve personally watched the enshittification of too many proprietary tools to ever build something I care about on top of one today, especially something which becomes so fundamental to the design of your application like a GUI toolkit. I know it sounds crazy, like you’d never bother forking your GUI framework anyway even when it’s open source. But I worked on an application built in C++ Builder, at a company with enough engineering talent and willpower that we would’ve forked the compiler internally to fix its problems and limitations had we been granted access to the source. Instead, I got to watch the product get held back by it year after year, hoping that Borland would care.
cfiggers 2y ago
Tsoding explored this project on a recent stream: https://youtu.be/aKk_r9ZwXQw?si=dvZAZkOX3xd7yjTw https://youtu.be/aKk_r9ZwXQw?si=dvZAZkOX3xd7yjTw
- nurettin 2y ago
  I got tsoding fatigue after youtube started suggesting him on an hourly basis. He's on ignore.
sylware 2y ago
Again, 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 ~70% of latest gcc speed (in my benchmarks on AMD zen2 x86_64).
- pjmlp 2y ago
  Cough, C23 and C2y roadmp.
  - Rochus 2y ago
    We are fortunately free to ignore "C23 and C2y" and stick with C89 (with the common extensions) or C99.
    - pjmlp 2y ago
      Applies to any programming language, feel free to use C++ARM for example. Until there is that special library that doesn't care about this target group of developers that want to stay in the past.
    - uecker 2y ago
      What are the specific things you do not like about C23 or the C2y road map (whatever this is, it is more random walk)? I have my own list of course, but overall I still have some hope that C2y does not turn out to be a total disaster.
      - Rochus 2y ago
        I've spent too little time with the recent standards/draft to give a specific answer. But I have a general attitude: C89 with extensions or C99 were just perfect for almost any purpuse; newer standards may well correct minor inadequacies or integrate things, that used to be implemented by proven libraries, directly into the language; but the price for these relatively minor improvements is high; people who write supposedly reusable code in the newer standards effectively force all older projects to switch to the newer standard; the costs of this are rarely justifiable. And there is C11 which made mandatory parts of the C99 standard optional, thus breaking backwards compatibility.
muth02446 2y ago
Shameless plug for another similar system: http://cwerg.org http://cwerg.org Less ambitious with a focus on (measurable) simplicity.
- Rochus 2y ago
  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/ 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"?
  - muth02446 2y ago
    Ultimately, the plan for Cwerg is to be self-hosting, so C++ is just another stepping stone. I am curious about the issues with C++17 (vs say C++11) though. About using C++: Cwerg is NOT going "all in" on C++ and tries to use as little STL as possible. There are some warts here and there that C++17 fixes and those are used by Cwerg - nothing major. There is also a lightweight C wrapper for Cwerg Backend. About not using C: I do not get the fetishizing of C. String handling is just atrocious, no concept of a span, no namespaces, poorer type system, etc. Cwerg is actually trying to fix these. If Cwerg was written in C instead of C++, a lot of the constructs would become MACRO-magic. About Backends: Currently supported are: 64 bit ARM, 32 bit ARM (no thumb), 64 bit x86 There are no plans to support 32 bit x86
    - Rochus 2y ago
      > I am curious about the issues with C++17 (vs say C++11) though. It's about dependability and bootstrapping. GCC 4.7 was the last version implemented in C, and it supports C++98/03 and a subset of C++11. > There are some warts here and there that C++17 fixes [..] nothing major But it's C++17 and thus requires many more bootstrap cycles until we have a compiler. I think a backend which only supports a subset of the features of a C++17 compiler should not depend on C++17, otherwise its usefulness is restricted by the availability of such a compiler. > I do not get the fetishizing of C. String handling is just atrocious... C is just a pretty primitive high-level language (with a very strange syntax) a compiler of which exists on almost any system. The next complexity step is C++98 (or the subset supported by cfront), which solves your issues and is even good enough to build something as complex as Qt and KDE. > There are no plans to support 32 bit x86 Ok, thanks. The support for ARM32 already enables many use cases.
mtlynch 2y ago
I 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." [0] https://handmadecities.com/media/seattle-2023/tb/ https://handmadecities.com/media/seattle-2023/tb/
bjourne 2y ago
Good 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.
- pjmlp 2y ago
  GraalVM, PyPy, naturally the more the merrier.
fguerraz 2y ago
Looking at the commit history inspires some real confidence! https://github.com/RealNeGate/Cuik/commits/master/ https://github.com/RealNeGate/Cuik/commits/master/
- wild_pointer 2y ago
  chicken (+558998, -997)
  - jamil7 2y ago
    Cursed. I had a coworker once would commit diffs like that but always with the message "Cleanup". The git history was littered with "Cleanup" commits that actually hid all kinds of stuff in them. If you pulled them up on it (or anything else) they went into defensive meltdown mode, so everyone on the team just accepted it and moved on.
    - tasty_freeze 2y ago
      Back in 1990 or so I worked at a networking company (Vitalink) that was using whatever source control was popular back then. I forget which one, but the important thing was that rather than allowing multiple check outs followed by resolve, that system would lock a file when it was opened for edit and nobody else could make edits until the file was checked in. One young developer checked out a couple files to "clean them up" with some refactoring. But because he changed some function interfaces, he needed to check out the files which called those functions. And since he was editing those files he decided to refactor them too. Pretty quickly he had more than half the files locked and everyone was beating on him for doing that. But because he had so many partial edits in progress and things weren't yet compiling and running, he prevented a dozen other people from doing much work for a few days.
- artemonster 2y ago
  went to write exactly that. Ambitions are great and I dont want to be dissuasive, but monumental tasks require monumental effort and monumental effort requires monumental care. That implies good discipline and certain "beauty" standards that also apply to commit messages. Bad sign :)
muke101 2y ago
If 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://github.com/google/souper, https://arxiv.org/pdf/1711.04422.pdf 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
- jcranmer 2y ago
  > 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. So one of the main problems you run into is that your elegant solution only works about 60-80% of the time. The rest of the time, you end up falling back onto near-unmaintainable, horribly inelegant kludges that end up having to exist because gee, real architectures are full of inelegant kludges in the first place. Recently, I've been working on a decompiler, and I started out with going for a nice, elegant solution that tries as hard as possible to avoid the nasty pile of switch statements. And this is easy mode--I'm not supporting any ugly ISA extensions, I'm only targeting ancient, simple hardware! And still I ran into the limitations of the elegant solution, and had to introduce ugly kludges to make it work. The saving grace is that I plan to rip out all of this manual work with a fully automatically-generated solution. Except that's only feasible in a decompiler, since the design of that solution starts by completely ignoring compatibility with assembly (ISAs turn out to be simpler if you think of them as "what do these bytes do" rather than "what does this instruction do")... and I'm worried that it's going to end up with inelegant kludges because the problem space more or less mandates it. > 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: One of the problems that Souper ran into is that LLVM IR is too abstract for superoptimization to be viable. Rather than the promise of an automatic peephole optimizer, it's instead morphed more into "here's some suggestions for possible peepholes". You need a really accurate cost model for superoptimization to work well, and since LLVM IR gets shoved through instruction selection and instruction scheduling, the link between LLVM instructions and actual instructions is just too tenuous to build the kind of cost model a superoptimizer needs (even if LLVM does have a very good cost model for the actual machine instructions!).
elvircrn 2y ago
No benchmarks yet?
Ygg2 2y ago
Does anyone else experience site disappearing on scroll?
muizelaar 2y ago
I thought the sea-of-nodes choice was interesting. V8 has been moving away from sea-of-nodes. Here's a video where Ben Titzer is talking about V8's reasons for moving away from sea-of-nodes: https://www.youtube.com/watch?v=Vu372dnk2Ak&t=184s https://www.youtube.com/watch?v=Vu372dnk2Ak&t=184s. Yasser, the author of Tilde, is is also in the video.
- o11c 2y ago
  TL;DW version: sea of nodes requires a scheduling pass, which was taking 20% of their compilation time. But it sounds like there's a lot of legacy baggage, so ...
  - negate32 2y ago
    My GCM doesn't take 20% of my compile times last I checked but even so, V8 is gonna be in a special camp because they're comparing against a compiler that doesn't do much code motion. LLVM does a lot of code motion so that "20%" is still being paid by LLVM during their hoisting and local scheduling passes.
einpoklum 2y ago
I'm not familiar with a lot of the acronyms and catch-phrases already in the first part of the article... let me try to make a bit of sense of this: IR = Intermediate Representation SSA = Single Static Assignment CFG = Control-Flow Graph (not Context-Free Grammar) And "sea of nodes" is this: https://en.wikipedia.org/wiki/Sea_of_nodes https://en.wikipedia.org/wiki/Sea_of_nodes ... IIANM, that means that instead of assuming a global sequence of all program (SSA) instructions, which respects the dependecies - you only have a graph with the partial order defined by the dependencies, i.e. individual instructions are nodes that "float" in the sea.
- e4m2 2y ago
  https://github.com/RealNeGate/Cuik/blob/5c6f6ef9bfa983eb358a7b44c8aec98f5c91c898/include/tb.h#L1-L22 https://github.com/RealNeGate/Cuik/blob/5c6f6ef9bfa983eb358a...
orliesaurus 2y ago
The maintainer said that LLVM has 10M lines of code making it too hard to improve, so he's building its own. That sounds weird to me: but good luck I guess?
coolThingsFirst 2y ago
Is it just me or I find it difficult to believe that 19 year olds can implement the LLVM alternative?
- uecker 2y ago
  I don't find this difficult to believe.
  - coolThingsFirst 2y ago
    Seems far fetched but ok
    - uecker 2y ago
      A bit. But Linus Torvalds was not much older when he wrote Linux.
- mbrubeck 2y ago
  Chris Lattner was 21 or 22 when he created LLVM.
- astrange 2y ago
  Compilers aren't that hard. You'll miss out on user requirements by not knowing about them, but getting older isn't a good way to solve that; instead getting more people to work on your project is. (But you probably need to be older to be a good project manager.)
- quesera 2y ago
  Never underestimate adolescents who are not distracted by ordinary teen drama. They exist, and have truly enviable amounts of time for projects. Also, don't overestimate compilers (or kernels). They can be much simpler than they might seem! The difficult/tedious parts are optimizations(!) and broad compatibility with bizarre real-world stuff.
- negate32 2y ago
  It's a game of knowledge and I have time, if you think I don't know what I'm doing please just call it out so I can politely disagree :P
ziofill 2y ago
Wow, my brain read “my LLM alternative” and I was genuinely confused for a while when reading the blog post :facepalm:
mshockwave 2y ago
I’m definitely happy to see this happening. But I would like to point out two ingredients that constitute LLVM’s success beyond academic merits: License and modularity. I’m not a lawyer so can’t say much about the first one, all I can say is that I believe license is one of the main reasons Apple switched to LLVM decades ago. Modularity, on the other hand, is one of the most crucial features of LLVM and something GCC struggles to catch up even nowadays. I really hope Tilde can adopt the modularity philosophy, provide building blocks rather than just tools
- pjmlp 2y ago
  Had it not been for GPL 3, or the resistance to have GCC being more modular, and Apple, followed by Google, would not have sponsored it. The idea behind LLVM isn't new per se, there have been other similar tools in the past, e.g. Amsterdam Compiler Toolkit.
- astrange 2y ago
  LLVM is not very modular though. For instance there's no backwards/forwards compatibility in the IR.
  - mshockwave 2y ago
    modular in terms of using only some of the LLVM libraries without the need to pull the entire compiler into your project. In fact, many of the LLVM libraries have absolutely nothing to do with LLVM IR and have zero dependency on it. For instance, LLVMObject and LLVMDebugInfoDWARF. You can use those libraries to build useful tools, like your own objdump or just use it to read debug info.
Night_Thastus 2y ago
I'm confused, is this some kind of re-post? I saw this exact same post with the exact same comments on it awhile ago. Could have been more than a couple of weeks. Very strange.
- jsnell 2y ago
  It was posted three days ago, and got re-upped by the mods via the the second chance pool[0]. [0] https://news.ycombinator.com/pool https://news.ycombinator.com/pool
laweijfmvo 2y ago
> It's been 20 years and cruft has built up, time for a "redo". Ah.. is this one of those "I rewrote it and it's better" things, but when people inevitably discover issues that "cruft" was handling the author will blame the user?
- rc_mob 2y ago
  What a strangely pessimistic and negative comment.
  - snowfarthing 2y ago
    I think this is more a problem with the nature of technology in general. If we want simple and fast, we can do that, but sometimes it doesn't cover the corner cases that the slow and complicated stuff does -- and as you fix those things, the "simple and fast" becomes "complicated and slow". But, as others have observed about GCC vs LLVM (with LLVM having had a similar life cycle), the added competition forced GCC to step up their game, and both projects have benefited from that competition -- even if, as time goes on, they get more and more similar to what each can do. I think all our efforts suffer from the effects of the Second Law of Thermodynamics: "You can't win. You can't break even. And it's the only game in town."
tester756 2y ago
You want to create LLVM alternative and you write it in C? I'm saying this as someone who uses LLVM daily and wishes that it was written in anything else than C/CPP, those languages bring so many cons that it is unreal. Slow compilation, mediocre tooling (cmake), terrible error messages, etc, etc. What's the point of starting with tech debt?
- teleforce 2y ago
  It will be so much refreshing if someone write LLVM alternative in D language, its compilation speed is much faster than many compiled languages. Having said that perhaps Tilde can be a good compiler addition for D in addition to the existing GDC (GCC), LCD (LLVM) and the reference compiler DMD. It's interesting to note that Odin is implementing its compiler alternative in Tilde maybe due to some unresolved issues and bugs in LLVM [1],[2]. [1] A review of the Odin programming language (2022): https://graphitemaster.github.io/odin_review/ https://graphitemaster.github.io/odin_review/ [2] Understanding the Odin Programming Language (97 comments): https://news.ycombinator.com/item?id=42348655 https://news.ycombinator.com/item?id=42348655
  - tester756 2y ago
    Why not in Go/C#/Rust/Java or Kotlin/etc?
- lerno 2y ago
  1. C is universal, any other language is a dependency. 2. If you're using something like C# or Kotlin or whatever, then you're not serious about compilation speed. 3. You will need to provide a C API anyway.
  - tester756 2y ago
    >C is universal, any other language is a dependency. Executable is executable, there's no magic in C code, it's just frontend for LLVM IR. >If you're using something like C# or Kotlin or whatever, then you're not serious about compilation speed. Do you have any good benchmarks about how big the difference is?
triilman 2y ago
I not understand about IR or compiler backend but I know another LLVM alternative like QBE. https://c9x.me/compile/ https://c9x.me/compile/
ThatGuyRaion 2y ago
I appreciate several things about this compiler already: MIT license (the king of licenses, IMHO. That's not an objective statement though) Written in easy to understand C. No python required to build it. (GCC requires perl, and I think that Perl is way easier to bootstrap then Python for LLVM) No Apple. I don't know if you all have seen some of the Apple developers talking with people but some of them are extremely condescending and demeaning towards people of non-formal CS backgrounds. I get it, in a world where you are one of the supreme developers it's easy to be that way but it's also just as bad as having people like Theo or historical Torvalds.
gergo_barany 2y ago
> a decent linear scan allocator which will eventually be replaced with graph coloring for optimized builds. Before setting out to implement 1980s-style graph coloring, I would suggest considering SSA-based register allocation instead: https://compilers.cs.uni-saarland.de/projects/ssara/ https://compilers.cs.uni-saarland.de/projects/ssara/ , I find the slides at https://compilers.cs.uni-saarland.de/projects/ssara/hack_ssara_ssa09.pdf https://compilers.cs.uni-saarland.de/projects/ssara/hack_ssa... especially useful. Graph coloring is a nice model for the register assignment problem. But that's a relatively easy part of overall register allocation. If your coloring fails, you need to decide what to spill and how. Graph coloring does not help you with this, you will end up having to iterate coloring and spilling until convergence, and you may spill too much as a result. But if your program is in SSA, the special properties of SSA can be used to properly separate these subphases, do a single spilling pass first (still not easy!) and then do a coloring that is guaranteed to succeed. I haven't looked at LLVM in a while, but 10-15 years ago it used to transform out of SSA form just before register allocation. If I had to guess, I would guess it still does so. Not destroying SSA too early could actually be a significant differentiator to LLVM's "cruft".
- gergo_barany 2y ago
  Also, for a different notion of "cruft", informally it seems to me like new SSA-based compilers tend to choose an SSA representation with basic block arguments instead of the traditional phi instructions. There are probably reasons for this! I'm not aware of a Sea of Nodes compiler with (some notion corresponding to) block arguments, but it might be fun to explore this when designing a new compiler from the ground up. Might be too late for TB, though.

361 points by davikr 2y ago

I dunno if "twice as fast as Clang" is very impressive. How fast is it compared to Clang 1.0? Also starting a new project like this in C is an interesting choice.

oguz-ismail 2y ago
> interesting choice No serious alternative
- IshKebab 2y ago
  Rust? Zig?
  - oguz-ismail 2y ago
    [flagged]
    - IshKebab 2y ago
      Ah yes, the 10th most popular general purpose programming language in the world is a meme language. Facepalm. I know you'll ask for a source on that so: https://www.jetbrains.com/lp/devecosystem-2024/ https://www.jetbrains.com/lp/devecosystem-2024/ Excluding HTML, CSS, Shell and SQL because they aren't general purpose programming languages. Excluding Typescript because it's really just type annotations for JavaScript.
      - oguz-ismail 2y ago
        > Based on the responses from 23,262 developers worldwide, Yeah
  - lerno 2y ago
    No, just no
- twic 2y ago
  Compilation is high-level work, so you could do it in any high-level language.

Rochus 2y ago

Cool. 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/ 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 the advantage in having a C implementation; Eigen is unfortunately developed in C++17, but I managed to backport the parts I'm using to a moderate C++11 subset (https://github.com/rochus-keller/Eigen https://github.com/rochus-keller/Eigen). There are different front-ends available, two C compilers among them. And - as mentioned - an optimizer would be great. EDIT: just found this podcast where the author gives more informations about the project goals and history (at least the beginning of the podcast is interesting): https://www.youtube.com/watch?v=f2khyLEc-Hw https://www.youtube.com/watch?v=f2khyLEc-Hw

wffurr 2y ago
What’s unfortunate about C++17? It has some nice features that build on C++11’s safety and ergonomic improvements.
- Rochus 2y ago
  You need a large, modern C++ compiler and standard library, which are not available for most older systems, and you're inviting an excess of dependencies because not all compilers support all parts of the newer C++ standards (in the same way), and require a lot more resources and newer versions of APIs and libraries, which further limits their usability on older systems. Furthermore, C89 and C++98 are much easier to bootstrap than a colossus like LLVM and Clang. The few "nice features" are perhaps enticing, but the costs they incur are disproportionate.
- o11c 2y ago
  For reference, GCC 4.7 (released March 2012) was the last build of GCC that is written in C, and supports almost all of the C++11 language (4.8.1, written in C++, finished the last bits) and a fair amount of the library. If you have to work on a system that hasn't been updated since 2014 or so (since it's fair enough to avoid the .0 releases), getting support for later C++ standards is significantly more complicated.

s3graham 2y ago

This looks pretty cool. I've been looking at all the "small" backends recently. It's so much nicer to work with one of them than trying to wrangle LLVM. QBE, MIR, & IR (php's) are all worth a look too. Personally I've settled on IR for now because it seemed to match my needs the most closely. It's actively developed, has aarch64 in addition to x64 (looks like TB has just started that?), does x64 Windows ABI, and seems to generate decent code quickly.

mungaihaha 2y ago

> I believe it's (LLVM) far too slow at compiling and far too big to be fixed from the inside What are you doing to make sure Tilde does not end up like this?

fermigier 2y ago
"You either die a hero or live long enough to see yourself become the villain".
- Ygg2 2y ago
  You either reinvent the wheel but square or live long enough to make it a circle.
snowfarthing 2y ago
I just had a random thought: perhaps it would be a good idea to have a project that doesn't do optimizations, but just focuses on fast compiling. Then again, I now can't help but wonder if LLVM (or even GCC) would be fast, if you just turned off all the optimizations ... (Of course, at this point, I can't help but think "you don't need to worry about the speed of compilation" in things like Common Lisp or Smalltalk, because everything is compiled incrementally and immediately, so you don't have to wait for the entire project to compile before you could test something ...)
- ajross 2y ago
  > Then again, I now can't help but wonder if LLVM (or even GCC) would be fast, if you just turned off all the optimizations ... It's not the optimizations really, it's the language front ends. Rust and C++ are extremely analysis-heavy. Try generating a comparable binary in C (or a kernel build, which is likely to be much larger!) and see how fast these compilers can be.
- christophilus 2y ago
  Go’s internal compiler / linker is kind of like that. So is qbe[0] iirc. https://c9x.me/compile/ https://c9x.me/compile/

melodyogonna 2y ago

Chris Lattner seems to have also created an alternative for LLVM - https://mlir.llvm.org/ https://mlir.llvm.org/ Because of how the architecture works, LLVM is one of the backends, but it doesn't have to be. Very interesting project, you could do a lot more IR processing before descending to LLVM (if you use that), that way you could give LLVM a lot less to do. Chris has said LLVM is fast at what it is designed to do - lower IR to machine code. However, because of how convoluted it can get, and the difficulty involved in getting information from some language-specific MIR to LLVM, languages are forced to generate tons upon tons of IR so as to capture every possible detail. Then LLVM is asked to clean up and optimize this IR. One thing to look out for is the problem of either losing language-specific information when moving from MIR to Low-level IR (be it Tilde or LLVM) or generating too much information, most of it useless.

_flux 2y ago
I wonder if one solution would be have tighter integration between the layers, so the backend could ask for some IR to be generated? Basically starting from the program entrypoints. This way the frontend wouldn't need to generate all the possible code up-front. Mind you, I've never written a compiler after that Uni course and touched LLVM IR a long time ago
- melodyogonna 2y ago
  That is how MLIR works. Basically you have multiple levels of IR, you can optimize each level until you get to the last level. It also has the advantage of being able to parallelize passes
zellyn 2y ago
I wonder if this question can attract any MLIR people to answer my question: From Chris Lattner's descriptions of LLVM vs MLIR in various podcasts, it seems like LLVM is often used as a backend for MLIR, but only because so much work has been put into optimizing in LLVM. It also seems like MLIR is strictly a superset of LLVM in terms of capabilities. Here's my question: It seems inevitable that people will eventually port all LLVM's smarts directly into MLIR, and remove the need to shift between the two. Is that right?

ksec 2y ago

>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 resulting binary were not as optimised, once those optimisation added it became slower. While LLVM was a wake up call to modernise GCC and make it faster. In the end competition made both a lot better. I believe some industry ( Gaming ) used to swear by VS Studio / MS Compiler / Intel Compiler or languages that depends / prefer the Borland ( What ever they are called now ) compiler. Its been very long since I last looked I am wondering if those two are still used or have we all merged mostly into LLVM / GCC?

pjmlp 2y ago
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).
- deleted 2y ago
  [deleted]
- s1gsegv 2y ago
  Borland as of a few years ago also ships a clang fork for C++ Builder, interestingly enough. It unfortunately does not solve all of the problems you encounter using C++ Builder in the modern age. I’ve personally watched the enshittification of too many proprietary tools to ever build something I care about on top of one today, especially something which becomes so fundamental to the design of your application like a GUI toolkit. I know it sounds crazy, like you’d never bother forking your GUI framework anyway even when it’s open source. But I worked on an application built in C++ Builder, at a company with enough engineering talent and willpower that we would’ve forked the compiler internally to fix its problems and limitations had we been granted access to the source. Instead, I got to watch the product get held back by it year after year, hoping that Borland would care.

cfiggers 2y ago

Tsoding explored this project on a recent stream: https://youtu.be/aKk_r9ZwXQw?si=dvZAZkOX3xd7yjTw https://youtu.be/aKk_r9ZwXQw?si=dvZAZkOX3xd7yjTw

nurettin 2y ago
I got tsoding fatigue after youtube started suggesting him on an hourly basis. He's on ignore.

sylware 2y ago

Again, 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 ~70% of latest gcc speed (in my benchmarks on AMD zen2 x86_64).

pjmlp 2y ago
Cough, C23 and C2y roadmp.
- Rochus 2y ago
  We are fortunately free to ignore "C23 and C2y" and stick with C89 (with the common extensions) or C99.
  - pjmlp 2y ago
    Applies to any programming language, feel free to use C++ARM for example. Until there is that special library that doesn't care about this target group of developers that want to stay in the past.
  - uecker 2y ago
    What are the specific things you do not like about C23 or the C2y road map (whatever this is, it is more random walk)? I have my own list of course, but overall I still have some hope that C2y does not turn out to be a total disaster.
    - Rochus 2y ago
      I've spent too little time with the recent standards/draft to give a specific answer. But I have a general attitude: C89 with extensions or C99 were just perfect for almost any purpuse; newer standards may well correct minor inadequacies or integrate things, that used to be implemented by proven libraries, directly into the language; but the price for these relatively minor improvements is high; people who write supposedly reusable code in the newer standards effectively force all older projects to switch to the newer standard; the costs of this are rarely justifiable. And there is C11 which made mandatory parts of the C99 standard optional, thus breaking backwards compatibility.

muth02446 2y ago

Shameless plug for another similar system: http://cwerg.org http://cwerg.org Less ambitious with a focus on (measurable) simplicity.

Rochus 2y ago
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/ 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"?
- muth02446 2y ago
  Ultimately, the plan for Cwerg is to be self-hosting, so C++ is just another stepping stone. I am curious about the issues with C++17 (vs say C++11) though. About using C++: Cwerg is NOT going "all in" on C++ and tries to use as little STL as possible. There are some warts here and there that C++17 fixes and those are used by Cwerg - nothing major. There is also a lightweight C wrapper for Cwerg Backend. About not using C: I do not get the fetishizing of C. String handling is just atrocious, no concept of a span, no namespaces, poorer type system, etc. Cwerg is actually trying to fix these. If Cwerg was written in C instead of C++, a lot of the constructs would become MACRO-magic. About Backends: Currently supported are: 64 bit ARM, 32 bit ARM (no thumb), 64 bit x86 There are no plans to support 32 bit x86
  - Rochus 2y ago
    > I am curious about the issues with C++17 (vs say C++11) though. It's about dependability and bootstrapping. GCC 4.7 was the last version implemented in C, and it supports C++98/03 and a subset of C++11. > There are some warts here and there that C++17 fixes [..] nothing major But it's C++17 and thus requires many more bootstrap cycles until we have a compiler. I think a backend which only supports a subset of the features of a C++17 compiler should not depend on C++17, otherwise its usefulness is restricted by the availability of such a compiler. > I do not get the fetishizing of C. String handling is just atrocious... C is just a pretty primitive high-level language (with a very strange syntax) a compiler of which exists on almost any system. The next complexity step is C++98 (or the subset supported by cfront), which solves your issues and is even good enough to build something as complex as Qt and KDE. > There are no plans to support 32 bit x86 Ok, thanks. The support for ARM32 already enables many use cases.

mtlynch 2y ago

I 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." [0] https://handmadecities.com/media/seattle-2023/tb/ https://handmadecities.com/media/seattle-2023/tb/

bjourne 2y ago

Good 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.

pjmlp 2y ago
GraalVM, PyPy, naturally the more the merrier.

fguerraz 2y ago

Looking at the commit history inspires some real confidence! https://github.com/RealNeGate/Cuik/commits/master/ https://github.com/RealNeGate/Cuik/commits/master/

wild_pointer 2y ago
chicken (+558998, -997)
- jamil7 2y ago
  Cursed. I had a coworker once would commit diffs like that but always with the message "Cleanup". The git history was littered with "Cleanup" commits that actually hid all kinds of stuff in them. If you pulled them up on it (or anything else) they went into defensive meltdown mode, so everyone on the team just accepted it and moved on.
  - tasty_freeze 2y ago
    Back in 1990 or so I worked at a networking company (Vitalink) that was using whatever source control was popular back then. I forget which one, but the important thing was that rather than allowing multiple check outs followed by resolve, that system would lock a file when it was opened for edit and nobody else could make edits until the file was checked in. One young developer checked out a couple files to "clean them up" with some refactoring. But because he changed some function interfaces, he needed to check out the files which called those functions. And since he was editing those files he decided to refactor them too. Pretty quickly he had more than half the files locked and everyone was beating on him for doing that. But because he had so many partial edits in progress and things weren't yet compiling and running, he prevented a dozen other people from doing much work for a few days.
artemonster 2y ago
went to write exactly that. Ambitions are great and I dont want to be dissuasive, but monumental tasks require monumental effort and monumental effort requires monumental care. That implies good discipline and certain "beauty" standards that also apply to commit messages. Bad sign :)

muke101 2y ago

If 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://github.com/google/souper, https://arxiv.org/pdf/1711.04422.pdf 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

jcranmer 2y ago
> 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. So one of the main problems you run into is that your elegant solution only works about 60-80% of the time. The rest of the time, you end up falling back onto near-unmaintainable, horribly inelegant kludges that end up having to exist because gee, real architectures are full of inelegant kludges in the first place. Recently, I've been working on a decompiler, and I started out with going for a nice, elegant solution that tries as hard as possible to avoid the nasty pile of switch statements. And this is easy mode--I'm not supporting any ugly ISA extensions, I'm only targeting ancient, simple hardware! And still I ran into the limitations of the elegant solution, and had to introduce ugly kludges to make it work. The saving grace is that I plan to rip out all of this manual work with a fully automatically-generated solution. Except that's only feasible in a decompiler, since the design of that solution starts by completely ignoring compatibility with assembly (ISAs turn out to be simpler if you think of them as "what do these bytes do" rather than "what does this instruction do")... and I'm worried that it's going to end up with inelegant kludges because the problem space more or less mandates it. > 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: One of the problems that Souper ran into is that LLVM IR is too abstract for superoptimization to be viable. Rather than the promise of an automatic peephole optimizer, it's instead morphed more into "here's some suggestions for possible peepholes". You need a really accurate cost model for superoptimization to work well, and since LLVM IR gets shoved through instruction selection and instruction scheduling, the link between LLVM instructions and actual instructions is just too tenuous to build the kind of cost model a superoptimizer needs (even if LLVM does have a very good cost model for the actual machine instructions!).

elvircrn 2y ago

No benchmarks yet?

Ygg2 2y ago

Does anyone else experience site disappearing on scroll?

muizelaar 2y ago

I thought the sea-of-nodes choice was interesting. V8 has been moving away from sea-of-nodes. Here's a video where Ben Titzer is talking about V8's reasons for moving away from sea-of-nodes: https://www.youtube.com/watch?v=Vu372dnk2Ak&t=184s https://www.youtube.com/watch?v=Vu372dnk2Ak&t=184s. Yasser, the author of Tilde, is is also in the video.

o11c 2y ago
TL;DW version: sea of nodes requires a scheduling pass, which was taking 20% of their compilation time. But it sounds like there's a lot of legacy baggage, so ...
- negate32 2y ago
  My GCM doesn't take 20% of my compile times last I checked but even so, V8 is gonna be in a special camp because they're comparing against a compiler that doesn't do much code motion. LLVM does a lot of code motion so that "20%" is still being paid by LLVM during their hoisting and local scheduling passes.

einpoklum 2y ago

I'm not familiar with a lot of the acronyms and catch-phrases already in the first part of the article... let me try to make a bit of sense of this: IR = Intermediate Representation SSA = Single Static Assignment CFG = Control-Flow Graph (not Context-Free Grammar) And "sea of nodes" is this: https://en.wikipedia.org/wiki/Sea_of_nodes https://en.wikipedia.org/wiki/Sea_of_nodes ... IIANM, that means that instead of assuming a global sequence of all program (SSA) instructions, which respects the dependecies - you only have a graph with the partial order defined by the dependencies, i.e. individual instructions are nodes that "float" in the sea.

e4m2 2y ago
https://github.com/RealNeGate/Cuik/blob/5c6f6ef9bfa983eb358a7b44c8aec98f5c91c898/include/tb.h#L1-L22 https://github.com/RealNeGate/Cuik/blob/5c6f6ef9bfa983eb358a...

orliesaurus 2y ago

The maintainer said that LLVM has 10M lines of code making it too hard to improve, so he's building its own. That sounds weird to me: but good luck I guess?

coolThingsFirst 2y ago

Is it just me or I find it difficult to believe that 19 year olds can implement the LLVM alternative?

uecker 2y ago
I don't find this difficult to believe.
- coolThingsFirst 2y ago
  Seems far fetched but ok
  - uecker 2y ago
    A bit. But Linus Torvalds was not much older when he wrote Linux.
mbrubeck 2y ago
Chris Lattner was 21 or 22 when he created LLVM.
astrange 2y ago
Compilers aren't that hard. You'll miss out on user requirements by not knowing about them, but getting older isn't a good way to solve that; instead getting more people to work on your project is. (But you probably need to be older to be a good project manager.)
quesera 2y ago
Never underestimate adolescents who are not distracted by ordinary teen drama. They exist, and have truly enviable amounts of time for projects. Also, don't overestimate compilers (or kernels). They can be much simpler than they might seem! The difficult/tedious parts are optimizations(!) and broad compatibility with bizarre real-world stuff.
negate32 2y ago
It's a game of knowledge and I have time, if you think I don't know what I'm doing please just call it out so I can politely disagree :P

ziofill 2y ago

Wow, my brain read “my LLM alternative” and I was genuinely confused for a while when reading the blog post :facepalm:

mshockwave 2y ago

I’m definitely happy to see this happening. But I would like to point out two ingredients that constitute LLVM’s success beyond academic merits: License and modularity. I’m not a lawyer so can’t say much about the first one, all I can say is that I believe license is one of the main reasons Apple switched to LLVM decades ago. Modularity, on the other hand, is one of the most crucial features of LLVM and something GCC struggles to catch up even nowadays. I really hope Tilde can adopt the modularity philosophy, provide building blocks rather than just tools

pjmlp 2y ago
Had it not been for GPL 3, or the resistance to have GCC being more modular, and Apple, followed by Google, would not have sponsored it. The idea behind LLVM isn't new per se, there have been other similar tools in the past, e.g. Amsterdam Compiler Toolkit.
astrange 2y ago
LLVM is not very modular though. For instance there's no backwards/forwards compatibility in the IR.
- mshockwave 2y ago
  modular in terms of using only some of the LLVM libraries without the need to pull the entire compiler into your project. In fact, many of the LLVM libraries have absolutely nothing to do with LLVM IR and have zero dependency on it. For instance, LLVMObject and LLVMDebugInfoDWARF. You can use those libraries to build useful tools, like your own objdump or just use it to read debug info.

Night_Thastus 2y ago

I'm confused, is this some kind of re-post? I saw this exact same post with the exact same comments on it awhile ago. Could have been more than a couple of weeks. Very strange.

jsnell 2y ago
It was posted three days ago, and got re-upped by the mods via the the second chance pool[0]. [0] https://news.ycombinator.com/pool https://news.ycombinator.com/pool

laweijfmvo 2y ago

> It's been 20 years and cruft has built up, time for a "redo". Ah.. is this one of those "I rewrote it and it's better" things, but when people inevitably discover issues that "cruft" was handling the author will blame the user?

rc_mob 2y ago
What a strangely pessimistic and negative comment.
- snowfarthing 2y ago
  I think this is more a problem with the nature of technology in general. If we want simple and fast, we can do that, but sometimes it doesn't cover the corner cases that the slow and complicated stuff does -- and as you fix those things, the "simple and fast" becomes "complicated and slow". But, as others have observed about GCC vs LLVM (with LLVM having had a similar life cycle), the added competition forced GCC to step up their game, and both projects have benefited from that competition -- even if, as time goes on, they get more and more similar to what each can do. I think all our efforts suffer from the effects of the Second Law of Thermodynamics: "You can't win. You can't break even. And it's the only game in town."

tester756 2y ago

You want to create LLVM alternative and you write it in C? I'm saying this as someone who uses LLVM daily and wishes that it was written in anything else than C/CPP, those languages bring so many cons that it is unreal. Slow compilation, mediocre tooling (cmake), terrible error messages, etc, etc. What's the point of starting with tech debt?

teleforce 2y ago
It will be so much refreshing if someone write LLVM alternative in D language, its compilation speed is much faster than many compiled languages. Having said that perhaps Tilde can be a good compiler addition for D in addition to the existing GDC (GCC), LCD (LLVM) and the reference compiler DMD. It's interesting to note that Odin is implementing its compiler alternative in Tilde maybe due to some unresolved issues and bugs in LLVM [1],[2]. [1] A review of the Odin programming language (2022): https://graphitemaster.github.io/odin_review/ https://graphitemaster.github.io/odin_review/ [2] Understanding the Odin Programming Language (97 comments): https://news.ycombinator.com/item?id=42348655 https://news.ycombinator.com/item?id=42348655
- tester756 2y ago
  Why not in Go/C#/Rust/Java or Kotlin/etc?
lerno 2y ago
1. C is universal, any other language is a dependency. 2. If you're using something like C# or Kotlin or whatever, then you're not serious about compilation speed. 3. You will need to provide a C API anyway.
- tester756 2y ago
  >C is universal, any other language is a dependency. Executable is executable, there's no magic in C code, it's just frontend for LLVM IR. >If you're using something like C# or Kotlin or whatever, then you're not serious about compilation speed. Do you have any good benchmarks about how big the difference is?

triilman 2y ago

I not understand about IR or compiler backend but I know another LLVM alternative like QBE. https://c9x.me/compile/ https://c9x.me/compile/

ThatGuyRaion 2y ago

I appreciate several things about this compiler already: MIT license (the king of licenses, IMHO. That's not an objective statement though) Written in easy to understand C. No python required to build it. (GCC requires perl, and I think that Perl is way easier to bootstrap then Python for LLVM) No Apple. I don't know if you all have seen some of the Apple developers talking with people but some of them are extremely condescending and demeaning towards people of non-formal CS backgrounds. I get it, in a world where you are one of the supreme developers it's easy to be that way but it's also just as bad as having people like Theo or historical Torvalds.

gergo_barany 2y ago

> a decent linear scan allocator which will eventually be replaced with graph coloring for optimized builds. Before setting out to implement 1980s-style graph coloring, I would suggest considering SSA-based register allocation instead: https://compilers.cs.uni-saarland.de/projects/ssara/ https://compilers.cs.uni-saarland.de/projects/ssara/ , I find the slides at https://compilers.cs.uni-saarland.de/projects/ssara/hack_ssara_ssa09.pdf https://compilers.cs.uni-saarland.de/projects/ssara/hack_ssa... especially useful. Graph coloring is a nice model for the register assignment problem. But that's a relatively easy part of overall register allocation. If your coloring fails, you need to decide what to spill and how. Graph coloring does not help you with this, you will end up having to iterate coloring and spilling until convergence, and you may spill too much as a result. But if your program is in SSA, the special properties of SSA can be used to properly separate these subphases, do a single spilling pass first (still not easy!) and then do a coloring that is guaranteed to succeed. I haven't looked at LLVM in a while, but 10-15 years ago it used to transform out of SSA form just before register allocation. If I had to guess, I would guess it still does so. Not destroying SSA too early could actually be a significant differentiator to LLVM's "cruft".

gergo_barany 2y ago
Also, for a different notion of "cruft", informally it seems to me like new SSA-based compilers tend to choose an SSA representation with basic block arguments instead of the traditional phi instructions. There are probably reasons for this! I'm not aware of a Sea of Nodes compiler with (some notion corresponding to) block arguments, but it might be fun to explore this when designing a new compiler from the ground up. Might be too late for TB, though.