Show HN: QBE – a new compiler back end

&gt; 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.<p>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&#x27;t escape, it gets promoted into an SSA value.

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

This is a wonderful idea! As a compiler person, I&#x27;m excited to see how well this works and wish you all the success in the world.<p>&gt; QBE aims to be a pure C embeddable backend that provides <i></i>70% of the performance of advanced compilers in 10% of the code.<i></i><p>This philosophy is very similar to that of vis [1], a vim-like editor that aims to have 80% of vim&#x27;s functionality in 1% of the code. I hope that more such project see the light of the day; I&#x27;m very interested in simpler programs and simpler ecosystems, even if that comes at the cost of features.<p>[1] <a href="https:&#x2F;&#x2F;github.com&#x2F;martanne&#x2F;vis" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;martanne&#x2F;vis</a>

Interesting project mpu. I like the stuff here:<p><a href="http:&#x2F;&#x2F;c9x.me&#x2F;compile&#x2F;doc&#x2F;llvm.html" rel="nofollow">http:&#x2F;&#x2F;c9x.me&#x2F;compile&#x2F;doc&#x2F;llvm.html</a><p>Especially the optimizations that get you the first 70%. I&#x27;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.<p>Now, back to correctness. Your project aims to be small, simple, and rigorous. That&#x27;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&#x2F; 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.<p>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 <i>great</i>.<p>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.

At times I feel that LLVM is quite a monster, and I really like your goals of keeping things small &amp; simple. Kudos!<p>Can you expand on your point about &quot;LLVM does NOT provide full C compatibility for you&quot;? I have specifically been hacking on calling conventions&#x2F;ABI stuff recently in LLVM and this &quot;well known&quot; problem is news to me.

How does this compare to libfirm[1]?<p>1. <a href="http:&#x2F;&#x2F;pp.ipd.kit.edu&#x2F;firm&#x2F;" rel="nofollow">http:&#x2F;&#x2F;pp.ipd.kit.edu&#x2F;firm&#x2F;</a>

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

Here&#x27;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.<p><pre><code> Assuming the upstream developers fail to deliver, it&#x27;s up to us to fix or workaround compiler problems as we encounter them; sometimes it&#x27;s as easy as finding out which patch has been commited upstream, but not backported to the version we use; and sometimes it&#x27;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&#x27;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&#x27;t avoid them as soon as you compile any nontrivial piece of code, and because we can&#x27;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&#x27;t match any real life use case). Who cares? Tomorrow&#x27;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&#x27;t be the only free software project doing so. </code></pre> -- <a href="http:&#x2F;&#x2F;marc.info&#x2F;?l=openbsd-misc&amp;m=137530560232232" rel="nofollow">http:&#x2F;&#x2F;marc.info&#x2F;?l=openbsd-misc&amp;m=137530560232232</a><p>( Previous discussion of this post on HN: <a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=9322259" rel="nofollow">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=9322259</a> )<p>I like that this project is in-line with these same goals.

QBE [1] is also a query language, Query by Example, developed at about the same time as SQL in the 1970s.<p>[1] <a href="https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;Query_by_Example" rel="nofollow">https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;Query_by_Example</a>

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

Any benchmarks of compile times vs other compilers?

&gt; Very good compatibility with C code<p>How much harder would it be to call C++?

If thé IL is text, and your goal is short understandable code, why not use a language like Python?<p>(Compiling it with Cython would allow you to provide a C api and library with only lib python as a dep)

&gt; Its small size serves both its aspirations of correctness ...<p>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.<p>The small size is an awesome property for <i>education</i> (both for the writer and the reader). For this purpose, it&#x27;s absolutely great, so kudos for that. :)