Earlier quoted context omitted.
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…
MLIR is less a specific IR and more a generic framework for expressing your own custom IR (which is itself composed of many pluggable IRs)--except these IRs are renamed "dialects." One of the MLIR dialects is the LLVM dialect, which can be lowered to LLVM IR. In the future, it's plausible that dialects for hardware ISAs would be added to MLIR, and thus it would be plausible to completely bypass the LLVM IR layer for…
Tilde, My LLVM Alternative
121–130 of 165 posts
Re: Tilde, My LLVM Alternative
#122I’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…
LLVM is not very modular though. For instance there's no backwards/forwards compatibility in the IR.
Re: Tilde, My LLVM Alternative
#123Chris 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…
Theoretically, yes -- taking years if not decades for sure. And set aside (middle-end) optimizations, I think people often forgot another big part of LLVM that is (much) more difficult to port: code generation. Again, it's not impossible to port the entire codegen pipeline, it just takes lots of time and you need to try really hard to justify the advantage of moving over to MLIR, which at least needs to show that codegen with MLIR brings X% of performance improvement.
Re: Tilde, My LLVM Alternative
#124Earlier quoted context omitted.
I write C every day and wrote C compiler. I know all all the issues it has very well, but it still a relatively simple language. It also not that difficult to parse. The lexer hack is interesting, because you can almost get away with using a context-free lexer, but you need this one hack. But this is not really a problem. People failing to read c declarations is also not the same thing as complexity, although I would…
I would argue that the problem of C is something else: It does not provide enough functionality out of the box. So instead of using some safe abstraction, people open-code their string manipulation or buffer management. This is then cumbersome and error prone, leading to complexity of the solution and safety issues which would could easily be avoided.
And we must not forget that, 100% "safe" high level code should never be trusted to be compiled into 100% safe machine code.
Re: Tilde, My LLVM Alternative
#125>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 late…
Re: Tilde, My LLVM Alternative
#126> 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?
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,…
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.
Re: Tilde, My LLVM Alternative
#127MIT 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.
Re: Tilde, My LLVM Alternative
#128>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…
Re: Tilde, My LLVM Alternative
#129> 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?
One of the big things which makes LLVM very slow is the abundance of passes, I believe I last counted 75 for an unoptimized function? My solution for this is writing more combined passes, due to the SoN design I'm combining a lot of things which are traditionally separate passes. For instance, my equivalent to "SimplifyCFG" "GVNPass", "InstCombine", "EarlyCSEPass" and "JumpThreadingPass" is one combined peephole solv…
I'm also confused why you believe LLVM didn't start out the exact same way?
I say this as one of the main people responsible for working on combined pass replacements in both GCC and LLVM for things that were reasonable to be combined.
I actually love destroying lots of passes in favor of better combined ones. In that sense, i'm the biggest fan in the world of these kinds of efforts.
But the reason these passes exist is not cruft, or 20 years of laziness, - it's because it's very hard to replace them with combined algorithms that are both faster, and achieve the same results.
What exactly do you plan on replacing GVN + Simplify CFG + Jump Threading + correlated value prop with?
It took years of cherrypicking research and significant algorithm development to develop algorithms for this that had reasonable timebounds, were faster, and could do better than all of them combined. The algorithm is quite complex, and it's hard to prove it terminates in all cases, actually. The number of people who understand it is pretty small because of the complexity. That's before you get to applied engineering of putting it in a production compiler.
These days, as the person originally responsible for it, i'd say it's not better enough for the complexity, even though it is definitely faster and more complete and would let you replace these passes.
Meanwhile, you seem to think you will mature everything and get there in a few years.
I could believe you will achieve some percent of GCC or LLVM's performance, but that's not the reason these passes exist. They exist because that is what it reasonably takes to achieve LLVM (and GCC's) performance across a wide variety of code, for some acceptable level of algorithm complexity and maintainability.
So if you told me you were only shooting for 80% across some particular subset code, i could believe 10-20 passes. If you told me you were going to build a different product that targets a different audience, or in a different way, i could maybe believe it.
But for what you say here, I think you vastly underestimate the difficult and vastly underappreciate the effort that goes into these things. This is hundreds of very smart people working on things for decades. It's one thing to have a healthy disrespect for the impossible. It's another to think you will, in a few years, outdo hundreds of smart, capable engineers on pure technical achievement.
That strikes me as somewhere between hubris and insanity.
People also pretty much stopped building and publishing general purpose compiler optimization algorithms a decade ago, moving towards much more specialized algorithms and ML focused things and whatnot.
This is because in large part, there isn't a lot left worth doing.
So unless you've got magic bullets nobody else has, either you won't achieve the same performance level, or it will be slow, or it will take you a significant amount of algorithm development and engineering well beyond "a few years".
I say this not to dissuade you, but to temper your apparent expectations and view.
Honestly - I wish you the best of luck, and hope you succeed at it.
Re: Tilde, My LLVM Alternative
#130Earlier quoted context omitted.
chicken (+558998, -997)
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.
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.