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

81–90 of 165 posts

Re: Tilde, My LLVM Alternative

#81

Post by fooker »

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…

All the important bits of MLIR are closed source and there’s no indication that’ll change anytime soon.

The big players have their own frontend, dialects, and mostly use LLVM backends. There’s very little common usable infrastructure that is upstreamed. Some of the upstreamed bits are missing large pieces.

Re: Tilde, My LLVM Alternative

#82

Post by snowfarthing »

rc_mob wrote: post #74
laweijfmvo wrote: post #73

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

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

Re: Tilde, My LLVM Alternative

#83

Post by marssaxman »

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…

They solve different problems. MLIR is not a backend, but a toolkit for defining intermediate representations ("dialects") and the passes which optimize them or lower from one to another. You can use MLIR to organize everything your compiler does between its front-end and its back-end; MLIR doesn't care where the IR comes from or what you ultimately do with it.

MLIR does include a couple dozen built-in dialects for common tasks - there's an "scf" dialect which defines loops and conditionals, for example, and a "func" dialect with function call and return ops - and it so happens that one of these built-in dialects offers a 1:1 representation of the operations and types found in LLVM IR.

If you choose to structure your compiler so that all of your other dialects are ultimately lowered into this MLIR-LLVM dialect, you can then pass your MLIR-LLVM output through a converter function to get actual LLVM-IR, which you can then provide to LLVM in exchange for machine code; but that is the extent of the interaction between the two projects.

Re: Tilde, My LLVM Alternative

#84

Post by o11c »

wffurr wrote: post #17
Rochus wrote: post #2

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/ ) ; 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…

What’s unfortunate about C++17? It has some nice features that build on C++11’s safety and ergonomic improvements.

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.

Re: Tilde, My LLVM Alternative

#85

Post by snowfarthing »

mungaihaha wrote: post #4

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

Re: Tilde, My LLVM Alternative

#86

Post by muth02446 »

Rochus wrote: post #76
muth02446 wrote: post #64

Earlier quoted context omitted.

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

I can commiserate. I did some bootstrapping of gcc 10 years ago and it was the most miserable experience ever. You make a change somewhere. Kick off "make" and 20 min later you get some bizarre error in some artifact that is hard to find, generated by a build system that is impossible to trace.

A self-hosting Cwerg will hopefully be much easier to bootstrap because of its size. But until then, why do you need the (continuous) bootstrapping. You can use a cached version of the bootstrapped C++ compiler or cross compile.

Re: Tilde, My LLVM Alternative

#87

Post by fooker »

apocalypses wrote: post #54
KolmogorovComp wrote: post #30

Earlier 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 massively disagree. It would have taken the author approximately 1 minute to write the following high quality hack-n-slash commit message: ``` Big rewrites * Rewrote X * Deleted Y * Refactored Z ``` Done

Different people work differently.

Spending a minute writing commit messages while prototyping something will break my flow and derail whatever I’m doing.

Re: Tilde, My LLVM Alternative

#88

Post by shipp02 »

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…

Given how long it takes for compilers to mature, by the time it's ready I didn't think anyone will care about x86. Similarly for c++11 vs 17. No?

Re: Tilde, My LLVM Alternative

#89

Post by Rochus »

pjmlp wrote: post #79
Rochus wrote: post #61

Earlier quoted context omitted.

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.

When refering to Pascal, I mean something like Turbo, Vax or Apple Pascal, i.e. the version used at the height of popularity. Original Pascal has much less degrees of freedom. And I have no reason to assume that Turbo or Apple Pascal have less possibilities for memory corruption, or are better specified.

Re: Tilde, My LLVM Alternative

#90

Post by uecker »

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.

While it has its fair share of quirks it is certainly not an "ultra-complex" language.
Post reply on HN