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.
Tilde, My LLVM Alternative
71–80 of 165 posts
Re: Tilde, My LLVM Alternative
#72Earlier quoted context omitted.
>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 This is generally true, though for small compiler backends they have the luxury to straight up refuse to support such use cases. Take QBE and Cranelift for example, the former lacks x8…
I think you are generally correct but the two examples you gave "triggered" me ;-) What damaged would there be if gcc or LLVM did decide to not support x87 anymore. It is not much different from dropping an ISA like IA64. You can still use the older compilers if you need to. Similarly, what is varargs used for? Pretty much only for C and its unfortunate printf, scanf stdlib calls. If a backend decides not support C,…
> What damaged would there be if gcc or LLVM did decide to not support x87 anymore.
For starters, you'd break every program using long double on x86.
And as far as "complexities of the x86 ISA" goes, x87 isn't really that high on the list. I mean, MMX is definitely more complex (and LLVM recently ripped out support for that). But even more complex than either of those would be anything touching AVX, AVX-512, or now AVX-10 stuff, and all the fun you get trying to build your systems to handle encoding the VEX or EVEX prefixes.
Re: Tilde, My LLVM Alternative
#73 > It's been 20 years and cruft has built up, time for a "redo".
Re: Tilde, My LLVM Alternative
#74> 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?
What a strangely pessimistic and negative comment.
Re: Tilde, My LLVM Alternative
#75Chris Lattner seems to have also created an alternative for LLVM - 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…
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…
I know of a few projects looking in that direction, each optimising for different things, and none getting near the capability of LLVM, which is going to take some time. I spoke with some of the core MLIR developers about this, and they're generally open to the notion, but it's going to take a lot of volunteer effort to get there, and it's not clear who the sherpa will be, especially given the major sponsors of the LLVM project aren't in a particular hurry. If you're interested in this feel free to look our paper up in a week or two, we've had a bit of trouble uploading it to arxiv but should be ready soon.
https://2025.cgo.org/details/cgo-2025-papers/39/A-Multi-Leve...
Here's a quick pres from the last dev meeting on how this can be leveraged to compile NNs to a RISC-V-based accelerator core: https://www.youtube.com/watch?v=RSTjn_wA16A&t=1s
Re: Tilde, My LLVM Alternative
#76Earlier quoted context omitted.
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…
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 us…
> 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.
Re: Tilde, My LLVM Alternative
#77I’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…
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.
Re: Tilde, My LLVM Alternative
#78Good 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.
GraalVM, PyPy, naturally the more the merrier.
Re: Tilde, My LLVM Alternative
#79Earlier quoted context omitted.
C itself is an ultra-complex language. I do not understand the mindset of the "C is simple" crowd. Is it nostalgia or romanticism for the past? If we want to devise a truly simple language, we need to start by realizing that C is just the Javascript of its day: hacked together in a weekend by someone who wished they were using a different language and then accidentally catapulted into the future by platform effects.
What aspects do you consider "ultra-complex"? I agree that it has a very strange syntax, many features of it being unknown to most people; but besides that, it's as easy as Pascal, isn't it?
Pascal doesn't have half as UB as C, or possibilities to memory corruption.
Pascal here meaning compilers people actually use, not ISO Pascal from 1976, people love their C extensions after all.
A for C's simplicity, one just needs to organise a pub quiz, using ISO, and key extensions as source of inspiration.
Re: Tilde, My LLVM Alternative
#80Earlier quoted context omitted.
Eh, when you're hacking away as a solo developer on something big and new I don't think this matters at all. In my current project I did about 200x commits marked "wip" before having enough structure and stability to bother with proper commit messages. Whatever lets you be productive until more structure is helpful.
Perhaps, but I still think it is lazy. A very nice counter example of someone with high commit standards can be seen in this repository: https://github.com/rmyorston/pdpmake/commits/master/
[deleted]