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

31–40 of 101 posts

Re: QBE vs. LLVM

#31

Post by mhh__ »

msla wrote: post #27
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…

Similar is C-- https://en.wikipedia.org/wiki/C-- https://github.com/nrnrnr/qc-- https://web.archive.org/web/20080822062234/http://www.cminus...

LLVM is much much much more than just the IR, e.g. LLVM's scheduling code is sufficiently abstract and compartmentalised that it can be used to (optimistically, last time I checked) predict performance of machine code not generated by LLVM (llvm-mca)

Re: QBE vs. LLVM

#32

Post by felixr »

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…

libFIRM is another one for the the list

https://pp.ipd.kit.edu/firm

edit: libFIRM vs LLVM https://pp.ipd.kit.edu/firm/LLVM.html

Re: QBE vs. LLVM

#34

Post by kohlerm »

I only hope that by we don't get a lot of new languages, which are not only not production ready but also poorly designed. ;)

Re: QBE vs. LLVM

#36

Post by bla3 »

pjmlp wrote: post #24
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.

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.

That table doesn't have greens for apple clang that are missing for regular clang. As far as I know they take some time integrating upstream llvm changes, so the two columns are due to that.

Historically they've been very good about upstreaming. Sometimes it takes a while, but so far everything made it to the public repo.

Re: QBE vs. LLVM

#37

Post by sligor »

> "Implementing a complete C ABI (with struct arguments and returns) is incredibly tricky, and not really a lot of fun."

This sounds like it should be wrapped as an helper library on top of LLVM and embedded inside LLVM. Why it is not the case ?

Re: QBE vs. LLVM

#38

Post by p_l »

pjmlp wrote: post #24
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.

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.

Bitcode was never compatible anyway, I'm more surprised that they have it in delivery pipeline than anything else.

Re: QBE vs. LLVM

#39

Post by dTal »

kohlerm wrote: post #34

I only hope that by we don't get a lot of new languages, which are not only not production ready but also poorly designed. ;)

What's the harm? Just don't use them.

Re: QBE vs. LLVM

#40

Post by throw0101a »

mhh__ wrote: post #29
Mutjake wrote: post #18

Earlier quoted context omitted.

If it was licensed under GPL, my bet is that Apple would not have adopted it at all.

That's entirely possible, but does it hurt their bottom line? They switched from GCC, because LLVM was available (to grow and eventually use). Their aversion to the GPL seems mostly cultural, which is interesting given that we skewer microsoft for their sins along those lines 20 years ago now.

Apple has an aversion to GPL 3 and not to GPL 2.x because of what 3 forces people to do. It's the same with FreeBSD: once libgcc_s went to 3 they could no longer use it.

It's the same reason why bash and rsync have not been upgraded on macOS to newer versions: they also started using GPL3.

Post reply on HN