Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Tilde, My LLVM Alternative

yasserarg.com

Post reply on HN
Print view View original

61–70 of 165 posts

Re: Tilde, My LLVM Alternative

#61

Post by Rochus »

kibwen wrote: post #58
sylware wrote: post #10

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…

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?

Re: Tilde, My LLVM Alternative

#62

Post by mshockwave »

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

Re: Tilde, My LLVM Alternative

#63

Post by whimsicalism »

ksec wrote: post #8

>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…

msvc is very much in third but it is one of the three that i think of when i think of c++ compilers

Re: Tilde, My LLVM Alternative

#64

Post by muth02446 »

Rochus wrote: post #18
muth02446 wrote: post #11

Shameless 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…

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

Re: Tilde, My LLVM Alternative

#65

Post by bruce343434 »

willvarfar wrote: post #27
ksec wrote: post #8

>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…

Back 20 or more years ago I used to do a lot of rec math competition programming and found that the metrowerks c++ compiler made massively faster programs than gcc, vsstudio, intel and everything else I tried then. This seemed to be simply down to variable alignment; the programs took more memory but ran much faster, particularly multi-core (which was still high end then). And this was on x86 where metrowerks weren't…

Memory access patterns are everything. Memory delay is almost always the bottleneck anyway. I have the feeling that more and more this is becoming common knowledge, and techniques like "struct of arrays" are becoming more wide spread and talked about.

Re: Tilde, My LLVM Alternative

#66

Post by zellyn »

melodyogonna wrote: post #6

Chris 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 port all LLVM's smarts directly into MLIR, and remove the need to shift between the two. Is that right?

Re: Tilde, My LLVM Alternative

#67

Post by o11c »

muizelaar wrote: post #31

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 . Yasser, the author of Tilde, is is also in the video.

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

Re: Tilde, My LLVM Alternative

#68

Post by muth02446 »

fuhsnn wrote: post #50
jcranmer wrote: post #35

Earlier quoted context omitted.

> 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 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, all this headache goes away. The problem is, of course, that the first thing every new backend designer does is to write a C frontend.

Re: Tilde, My LLVM Alternative

#70

Post by jcranmer »

zellyn wrote: post #66
melodyogonna wrote: post #6

Chris 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…

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 optimizations. But the final codegen layer of LLVM IR is not a simple thing (I mean, LLVM itself has three different versions of it), and the fact that GlobalISel hasn't taken over SelectionDAG after even a decade of effort should be a sign of how difficult it is to actually replicate that layer in another system to the point of replacing existing work.

Post reply on HN