Is it just me or I find it difficult to believe that 19 year olds can implement the LLVM alternative?
Tilde, My LLVM Alternative
41–50 of 165 posts
Re: Tilde, My LLVM Alternative
#42Earlier quoted context omitted.
Cough, C23 and C2y roadmp.
We are fortunately free to ignore "C23 and C2y" and stick with C89 (with the common extensions) or C99.
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.
Re: Tilde, My LLVM Alternative
#43Earlier quoted context omitted.
Cough, C23 and C2y roadmp.
We are fortunately free to ignore "C23 and C2y" and stick with C89 (with the common extensions) or C99.
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.
Re: Tilde, My LLVM Alternative
#44Again, 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…
It is great to see some new C tooling emerge. I will likely make my own C FE public some time but it now uses some toy backend which needs be replaced...
Re: Tilde, My LLVM Alternative
#45Chris 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 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
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
Re: Tilde, My LLVM Alternative
#46I 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.
> interesting choice
No serious alternative
Re: Tilde, My LLVM Alternative
#47Re: Tilde, My LLVM Alternative
#48Is it just me or I find it difficult to believe that 19 year olds can implement the LLVM alternative?
I don't find this difficult to believe.
Re: Tilde, My LLVM Alternative
#49Earlier quoted context omitted.
Not really. In the initial phase of a project there is usually so much churn than enforcing proper commit messages is not worth it, until the dust settle down.
I am deeply suspicious of anyone who doesn't bother or who is unable to explain this churn. For the right kind of people, this is an excellent opportunity to reflect: why is there churn? Why did the dust not settle down? Why was the initial approach wrong and reworked into a new approach? I can understand this if you are coding for a corporate. But if it's your own project, you should care about it enough to write go…
Is your objection to the inevitable fact that requirements churn early on (regardless whether you're doing agile or waterfall)?
Or is your objection that solo devs code up prototypes and toy with ideas in live code instead of just in their mental VM in grooming sessions?
Or is your objection that you don't think early prototypes and demos should be available in the source tree?
Re: Tilde, My LLVM Alternative
#50If 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 part…
> 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 onl…
>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 x87 support [1], the latter doesn't support varargs[2]; which means either of them support the full x86-64 ABI for C99.
[1]https://github.com/michaelforney/cproc?tab=readme-ov-file#wh...