Show HN: QBE – a new compiler back end • Hacker News Board

Show HN: QBE – a new compiler back end

#1

Post by mpu » Sat, Apr 23, 2016, 1:56 PM UTC

Show HN: QBE – a new compiler back end
c9x.me

Re: Show HN: QBE – a new compiler back end

#2

Post by gravypod » Sat, Apr 23, 2016, 3:13 PM UTC

I've always found this sort of "I'm going to make my own" approche as being the best for innovation. I really hope this goes through and continues development.

Re: Show HN: QBE – a new compiler back end

#3

Post by mpu » Sat, Apr 23, 2016, 3:25 PM UTC

gravypod wrote: post #2

I've always found this sort of "I'm going to make my own" approche as being the best for innovation. I really hope this goes through and continues development.

Thank you for your words. It is often called NIH, but eh, I learned a lot! And I think that I made some modest improvements over LLVM, you can check them out in my comparison at http://c9x.me/compile/doc/llvm.html

Re: Show HN: QBE – a new compiler back end

#4

Post by npx » Sat, Apr 23, 2016, 3:38 PM UTC

How does this compare to libfirm[1]?

1. http://pp.ipd.kit.edu/firm/

Re: Show HN: QBE – a new compiler back end

#5

Post by mpu » Sat, Apr 23, 2016, 3:55 PM UTC

npx wrote: post #4

How does this compare to libfirm[1]? 1. http://pp.ipd.kit.edu/firm/

It's much much smaller (I think libfirm is over 100kloc, QBE is about 6k).

But the major difference is the IL: I use a human-readable and easily-printable text IL. This means that you don't need a graph-viewing tool to read the IL (it's just text) and that you can modify the IL between two passes super easily. This simple IL is a blessing when debugging a compiler.

I think QBE also has better support for the x64 ABI.

Finally, it is much less advanced (less optimizations, less tested) than libfirm and supports only x64 as a target.

This is a sketchy comparison.

Re: Show HN: QBE – a new compiler back end

#6

Post by mioelnir » Sat, Apr 23, 2016, 3:59 PM UTC

This confuses me. The title says it's an alternative, but the text says it does not intend to solve all problems of industry-grade languages.

Which to me reads as Qbe being entirely differently scoped, and therefor not an alternative.

Re: Show HN: QBE – a new compiler back end

#7

Post by mpu » Sat, Apr 23, 2016, 4:01 PM UTC

mioelnir wrote: post #6

This confuses me. The title says it's an alternative, but the text says it does not intend to solve all problems of industry-grade languages. Which to me reads as Qbe being entirely differently scoped, and therefor not an alternative.

It's an alternative if you fit in the use case. I did not try to clone LLVM.

Re: Show HN: QBE – a new compiler back end

#8

Post by munin » Sat, Apr 23, 2016, 4:10 PM UTC

> Implementing SSA construction is hard. To save its users from having to implement it, LLVM provides stack slots. This means that one increment of a variable v will be composed of three LLVM instructions: one load, one add, and one store.

This is just wrong, though! LLVM provides stack slots for a good reason: stack allocated variables can escape. You need a place in memory to stick them. If mem2reg can prove that the stack allocated variable doesn't escape, it gets promoted into an SSA value.

Re: Show HN: QBE – a new compiler back end

#9

Post by hobo_mark » Sat, Apr 23, 2016, 4:12 PM UTC

> Very good compatibility with C code

How much harder would it be to call C++?

Re: Show HN: QBE – a new compiler back end

#10

Post by KenoFischer » Sat, Apr 23, 2016, 4:16 PM UTC

hobo_mark wrote: post #9

> Very good compatibility with C code How much harder would it be to call C++?

Depends how much of C++ you need. In full generality you need a C++ compiler in the calling compilation unit (inlining, template instantiation, etc.). The name mangling and ABI itself really isn't that hard.