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

81–90 of 101 posts

Re: QBE vs. LLVM

#81

Post by richardwhiuk »

bla3 wrote: post #36
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.

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.

Definitely got sympathy for that position. Upstreaming changes often takes a long time to get across context, get community buy in to changes, get approval cut a release, whereas internally, it's often just a code review, which can be prioritised according to business needs.

It's quite common for long standing forks to exist, where changes get pushed upstream from the fork, and the fork gets periodically re-cut.

Re: QBE vs. LLVM

#82

Post by rrss »

segfaultbuserr wrote: post #62
throw0101a wrote: post #60

Earlier quoted context omitted.

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

Can you elaborate it a bit? I didn't see anything that suggested "rms didn't get the email because of the unique way he does email."

probably based on this: https://lists.gnu.org/archive/html/emacs-devel/2015-02/msg00...

I don't understand the bits about RMS' email configuration, but in that message in 2015 he indicated that he did not know about the offer in 2005 to give copyright of LLVM to the FSF.

Re: QBE vs. LLVM

#83

Post by badsectoracula »

jcranmer wrote: post #65
worldsayshi wrote: post #19

Earlier quoted context omitted.

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.

> Are there any big downsides to compiling to C instead of LLVM? Well, for starters, you have to import all of C's undefined behavior, so it would be basically impossible to implement, e.g., 2's complement signed integer arithmetic.

Strictly speaking it isn't impossible, just much slower since you'd have to implement on software what the hardware does.

In practice though pretty much every compiler that uses that as an optimization has a flag to disable it and chances are you'll be needing to use other system and/or compiler specific stuff anyway.

Re: QBE vs. LLVM

#84

Post by throw0101a »

badsectoracula wrote: post #78
akavel wrote: post #71

Earlier quoted context omitted.

Honestly curious what's the thing that "[GPLv]3 forces people to do" in context of those cases? IANAL but interested in perspective of choosing license for some of my current and future works

Not lock down people's devices basically. [L]GPLv3 requires that people are able to replace the [L]GPLv3'd binaries in their own devices if they want to (so they actually take advantage of the code being FLOSS instead of some nice theoretical novelty - ie. it is nice that my router uses Linux and find it amusing that it comes with the GPLv2 printed out, but what is the point if i can't open it up and fix/change some…

See also "Why is FreeBSD deprecating GCC in favor of Clang/LLVM?":

* https://unix.stackexchange.com/questions/49906/why-is-freebs...

GPL3 is more restrictive than GPL2, which in turn is more restrictive than BSD/MIT, in the name of allowing other freedoms for end-users.

Re: QBE vs. LLVM

#86

Post by parkovski »

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.

This is surprising for me, I thought LLVM abstracted away platform ABIs.

Re: QBE vs. LLVM

#87

Post by pjmlp »

mech422 wrote: post #80
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…

No one mentioned the Purdue Compiler Construction kit yet? Weren't they and the Amsterdam compiler kit the 2 'big ones' back in the day ?

Yes, big failure forgeting about it.

Re: QBE vs. LLVM

#88

Post by waynecochran »

Doesn't allowing non-SSA forms like

     %v =w add %v, 1.
defeat the purpose of using SSA in the first place? If this form is allowed, then I can not rely on `%v` having an immutable value which is much of the reason why we use SSA in the first place.

Re: QBE vs. LLVM

#89

Post by legulere »

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.

GCC would not have taken it anyway, they tried to prevent parts of GCC getting used independently or as a library to keep the lock-in to GNU, while the architecture of LLVM is of embeddable reusable libraries.
Post reply on HN