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

QBE vs. LLVM

c9x.me

Post reply on HN
Print view View original

51–60 of 101 posts

Re: QBE vs. LLVM

#51

Post by bjornjajayaja »

mhh__ wrote: post #30
pjmlp wrote: post #24

Earlier quoted context omitted.

Apple doesn't upstream of their changes already, hence why you have a specific Apple column on cppreference. https://en.cppreference.com/w/cpp/compiler_support And the bitcode used by Apple Store for application delivery isn't 100% like the LLVM bitcode.

Hence why I said it was a sign of the future rather than a prediction. It's not going to get any better for software freedom, especially as we move into the cloud. We live in a post-FSF world, I think people are taking for granted the bean counters playing nice with open source software.

We need software that works on the client side sans internet connection. Devices are really powerful these days so it’s funny things move to the cloud. It’s funny I’ve been using cloud storage for the past several years but I wonder why I don’t just back up to external drive or two. The convenience doesn’t buy much. I think folks really buy into laziness and technology hype. But fundamentally not much had changed in the software space compared to 20 years ago.

Re: QBE vs. LLVM

#52

Post by Rochus »

fanf2 wrote: post #50
pjmlp wrote: post #11

Also to note, LLVM isn't the first compiler toolchain of its kind. Notable mentions, IBM's research project on PL.8 while developing their first RISC designs. https://rsim.cs.uiuc.edu/arch/qual_papers/compilers/auslande... https://pdfs.semanticscholar.org/3288/fc042cd474f0ec93d67753... https://rishiheerasing.net/modules/hca2102/paper/cocke.pdf The Amsterdam Compiler Toolkit, http://tack.sourceforge.net/ https://githu…

Also TenDRA http://www.tendra.org/ (which is about 30 years old). TenDRA is designed for front-ends to compile to ANDF, an "architecture-neutral distribution format" which is kind of like LLVM bitcode but different. Sadly it never really gained any lasting momentum as an open source project, though it currently has a few active maintainers. And much more recently there's Cranelift https://github.com/bytecodealliance/…

Interesting. Had a look at http://www.tendra.org/developer-orientation; seems to be even more complex than LLVM. Didn't find out yet, what backends it actually supports.

Re: QBE vs. LLVM

#53

Post by Rochus »

rurban wrote: post #41
Rochus wrote: post #25

Earlier quoted context omitted.

why?

Because llvm is unusable for a dynamic language VM. The compile-times are too slow, it's way too big. cranelift is also big, but has sensible staged optimizers. I.e. it doesn't behave like java or llvm.

> cranelift is also big, but has sensible staged optimizers

LLVM gives you the freedom to decide what optimizers to use. But it's true it is too big for many applications, even if there are build options for different sizes.

Re: QBE vs. LLVM

#54

Post by jules »

ashton314 wrote: post #3

I’m going to be building a compiler over Christmas break, and I was thinking of targeting the LLVM toolset. This will be my second compiler; first one emitted x86 directly. Should I consider switching to QBE? I’m more focused on compiler passes that I want to write; register allocation, etc. is not my thing. I’m going to be working with CPS-conversion ans stuff like that. Does anyone have any good tutorials for using…

Consider generating WASM.

Re: QBE vs. LLVM

#55

Post by segfaultbuserr »

mhh__ wrote: post #17
phendrenad2 wrote: post #14

Earlier quoted context omitted.

Interesting. Programmers today do tend to think that LLVM is a revolutionary miracle, and border on worshipping it's creator.

LLVM does seem to be explicitly designed from the start to be "industry"-worthy rather than just academic research, though. It was actually offered to GNU years ago but (if I read the thread correctly) rms didn't get the email because of the unique way he does email. It's a shame it's not under the GPL, you can already see a sign of the future (present?) in apple not upstreaming their backends.

>It was actually offered to GNU years ago but (if I read the thread correctly) rms didn't get the email because of the unique way he does email.

Interesting anecdote. Do you have a source for that?

Re: QBE vs. LLVM

#56

Post by hated »

bjornjajayaja wrote: post #51
mhh__ wrote: post #30

Earlier quoted context omitted.

Hence why I said it was a sign of the future rather than a prediction. It's not going to get any better for software freedom, especially as we move into the cloud. We live in a post-FSF world, I think people are taking for granted the bean counters playing nice with open source software.

We need software that works on the client side sans internet connection. Devices are really powerful these days so it’s funny things move to the cloud. It’s funny I’ve been using cloud storage for the past several years but I wonder why I don’t just back up to external drive or two. The convenience doesn’t buy much. I think folks really buy into laziness and technology hype. But fundamentally not much had changed in…

You already know why you don't do backups to a local hard drive. And you won't start doing it either. Don't kid yourself, cloud is convenience.

Re: QBE vs. LLVM

#57

Post by burlesona »

sanxiyn wrote: post #46

> Implementing a complete C ABI (with struct arguments and returns) is incredibly tricky, and not really a lot of fun. This is so true. Rust does it here: https://github.com/rust-lang/rust/tree/master/compiler/rustc... and it's a lot of code for no good reasons.

Why does LLVM work that way?

Re: QBE vs. LLVM

#58

Post by chongli »

mhh__ wrote: post #30
pjmlp wrote: post #24

Earlier quoted context omitted.

Apple doesn't upstream of their changes already, hence why you have a specific Apple column on cppreference. https://en.cppreference.com/w/cpp/compiler_support And the bitcode used by Apple Store for application delivery isn't 100% like the LLVM bitcode.

Hence why I said it was a sign of the future rather than a prediction. It's not going to get any better for software freedom, especially as we move into the cloud. We live in a post-FSF world, I think people are taking for granted the bean counters playing nice with open source software.

I still hold out hope that things will get better in the future. Eventually Moore’s law will truly end. We will have to stop once we run up against hard physical limitations.

Why is this a reason for optimism? Because it shifts the outlet for innovation elsewhere. Costs of manufacturing will drop as competition in the fab space increases. I think RISC-V is a sign of things to come. There is great potential for open and amateur hardware.

Re: QBE vs. LLVM

#59

Post by arc-in-space »

worldsayshi wrote: post #19
siraben wrote: post #4

Earlier quoted context omitted.

Sounds like you want to compile a functional language. The best tutorial (in terms of being self-contained and being understandable in entirety) I've seen to compile FP to C is[0], I'd imagine that retargeting to LLVM wouldn't be that difficult either. [0] https://github.com/jozefg/pcf

Are there any big downsides to compiling to C instead of LLVM? I would assume that it would be less performant but it feels like a shallow preconception.

It's somewhat more constricting, certain types of compiler magic are hard to reproduce in plain C. For instance, dealing with things that need to be stack-aware, such as a GC or tail recursion, takes epic hacks like the Boehm GC or the "Cheney on the MTA" trick. You're also stuck with the C calling convention.

Plus, while generating C is simple, you're entirely on your own. With LLVM IR, you benefit from its infrastructure, the optimization passes and other LLVM-based tools, so you don't need to reinvent the wheel as much. In the end, you'll need some kind of IR anyway, and LLVM is a good place to start.

Re: QBE vs. LLVM

#60

Post by throw0101a »

segfaultbuserr wrote: post #55
mhh__ wrote: post #17

Earlier quoted context omitted.

LLVM does seem to be explicitly designed from the start to be "industry"-worthy rather than just academic research, though. It was actually offered to GNU years ago but (if I read the thread correctly) rms didn't get the email because of the unique way he does email. It's a shame it's not under the GPL, you can already see a sign of the future (present?) in apple not upstreaming their backends.

> It was actually offered to GNU years ago but (if I read the thread correctly) rms didn't get the email because of the unique way he does email. Interesting anecdote. Do you have a source for that?

Perhaps this?

* https://gcc.gnu.org/legacy-ml/gcc/2005-11/msg00888.html

Post reply on HN