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

Show HN: QBE – a new compiler back end

c9x.me

Post reply on HN
Print view View original

11–20 of 72 posts

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

#11

Post by dang »

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

We've taken 'LLVM' out of the title above, since experience has shown that discussions about titles tend to be off-topic and/or shallow. We also added 'Show HN' since this is your own work. Good luck!

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

#12

Post by nickpsecurity »

Interesting project mpu. I like the stuff here:

http://c9x.me/compile/doc/llvm.html

Especially the optimizations that get you the first 70%. I've been asking optimization people as I see them to do a survey of various methods to find the smallest collection that provide the hugest benefit. This will help people writing new compilers and formal verification community get a head start.

Now, back to correctness. Your project aims to be small, simple, and rigorous. That's perfect time to use methods for higher assurance software or design yours to work with them easily. So, I suggest trying Design-by-Contract w/ interface checks, some static analysis tools, or even something like Softbound+CETS that makes C safer automatically. I also usually recommend writing compilers in something like Ocaml as it prevents lots of bugs and easier to do.

Also, if you do Ocaml or safe imperative, you can always do two implementations side-by-side in the safe language and in portable C. You run tests, analysis, etc available for each one. Problems in one might be problems in the other. Regardless, though, you get the benefits of the safer language by default with a C implementation if you absolutely need it. Many of us have used this with Sandia Labs even doing it for hardware with ML and hardware language of a Java processor that came out great.

So, I challenge you to try to push the envelope by using some available techniques and tools to boost the assurance of your code. Preferably getting it off C, too, due to all the errors it (esp pointers) introduce into the compilers.

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

#13

Post by jklontz »

munin wrote: post #8

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

Yes! And I would also add that:

> LLVM IL is more cluttered with type annotations and casts.

With LLVM moving to typeless pointers[1], this will be less true in the future than it is now.

[1] https://groups.google.com/forum/#!topic/llvm-dev/vphBegBWyyE

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

#14

Post by munin »

jklontz wrote: post #13
munin wrote: post #8

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

Yes! And I would also add that: > LLVM IL is more cluttered with type annotations and casts. With LLVM moving to typeless pointers[1], this will be less true in the future than it is now. [1] https://groups.google.com/forum/#!topic/llvm-dev/vphBegBWyyE

I don't know if that would alleviate the authors concern, because (as I understand that proposal) the type information is still present, it's just bolted into the load/store/GEP instructions now.

Nothing is stopping you from writing LLVM that doesn't use types though! That's entirely a front end decision. If you wanted to, in your front end, you could never emit record or array types and do book keeping on cells in memory entirely on your own using pointer arithmetic / pointertoint / inttopointer. Doing so is entirely at the expense of the speed of the generated code though!

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

#15

Post by nickysielicki »

Here's an excerpt from a 2013 OpenBSD mailing list post about the state of compilers, whose points still are still valid in 2016, and I think it has some relevance to this submission.

    Assuming the upstream developers fail to deliver, it's up to us to fix
    or workaround compiler problems as we encounter them; sometimes it's as
    easy as finding out which patch has been commited upstream, but not
    backported to the version we use; and sometimes it's a genuine issue
    which may or may not have been reported in the latest compiler version,
    and we are on our own. When this happens, we can only rely upon our
    developer skills and intimacy with the compiler.

    A few of our developers have, over the years, become unafraid of gcc,
    and able to investigate issues, backport fixes, and fix or work around
    bugs: I'll only mention niklas@, espie@, etoh@ and otto@, and hope the
    few others will forgive me for not listing their names. This has not
    been an easy road, to say the least. Now, another few of our developers
    are working on building a similar knowledge of llvm. I wish them a lot
    of luck, and I will try to join them in the near future.

    In the meantime I am not sure they feel confident enough to support
    switching the most popular OpenBSD platforms from gcc to llvm.

    In a few months or years from now, things will be different...

    ...but there is something I wish would happen first.

    An LTS release of an open source compiler.
    Because all compilers nowadays are full of subtle bugs, but so many of
    them than you can't avoid them as soon as you compile any nontrivial
    piece of code, and because we can't afford to going back to assembly, we
    need a compiler we can trust.

    GCC, as well as LLVM, have Fortune 500 companies backing them, paying
    smart developers to work fulltime on these projects.

    Yet none of them dares to provide a long time support version. Bugs in
    version N are fixed in version N+1, but new bugs are introduced. And
    noone cares about trying to settle things down and produce a compiler
    one can trust (because version N+1 runs 3.14% faster in the loonystones
    benchmark which doesn't match any real life use case). Who cares?
    Tomorrow's compiler will generate code which will complete an infinite
    loop in less than 5 seconds; stay tuned for more accomplishments!

    The free software world needs an LTS compiler. The last de-facto LTS
    compiler we have had was gcc 2.7.2.1, and it is too old to compile
    modern C and C++ code.

    Should a free software LTS compiler appear (be it a gcc fork, or an llvm
    fork, or something else), then OpenBSD would consider using it, very
    seriously. And we probably wouldn't be the only free software project
    doing so.
-- http://marc.info/?l=openbsd-misc&m=137530560232232

( Previous discussion of this post on HN: https://news.ycombinator.com/item?id=9322259 )

I like that this project is in-line with these same goals.

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

#17

Post by chubot »

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.

Yeah, I wouldn't call it an LLVM alternative at all, because it doesn't support C++. But there is a comparison here:

http://c9x.me/compile/doc/llvm.html

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

#18

Post by ante_annum »

Ace17 wrote: post #16

Can QBE do coroutines (e.g 'yield')? Or maybe it's a front-end issue only?

coroutines and yielding are a pretty high-level concept that I wouldn't expect to see in a backend, but there's a really great explanation of how to map them to low-level concepts here: http://llvm.lyngvig.org/Articles/Mapping-High-Level-Construc...

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

#19

Post by Drup »

> Its small size serves both its aspirations of correctness ...

No, a compiler (hell, a software) written in C is not correct, period. If you want a C compiler that has slight chances to be correct, you use compcert.

The small size is an awesome property for education (both for the writer and the reader). For this purpose, it's absolutely great, so kudos for that. :)

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

#20

Post by mpu »

munin wrote: post #8

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

Then maybe I did not express myself in the best terms. QBE definitely supports stack slots and their registerization! Minic, a small C frontend shipped with QBE makes use of them.

The difference is that LLVM forces you to use them even when you know your locals do not escape (i.e. your source language is Pascal), QBE doesn't.

So, LLVM makes you use stack slots for two independent problems: 1. Compiling languages like C where locals can escape, and 2. Avoiding to construct SSA form in the frontend. In QBE, you use stack slots (alloc4, alloc8) to solve 1, but to solve 2, you can simply emit non-ssa form and QBE will fixup things for you.

Post reply on HN