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

41–50 of 72 posts

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

#41

Post by andrewchambers »

riscy wrote: post #40

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

In llvm you cannot just pass or return structs, every frontend needs to explicitly handle the details of when and how to registerize structs to handle the system V abi for example.

That code is not so trivial to do yourself actually.

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

#42

Post by andrewchambers »

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…

qbe allows both stack slots like llvm, or directly inputting non ssa code which is automatically turned to ssa form.

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

#43

Post by andrewchambers »

nickpsecurity wrote: post #12

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

My qbe C frontend is actually written in myrddin which is a lot like rust/ocaml.

To be honest, C is not well suited to places where there is adversarial input such as servers, but when it comes to logical correctness of code I do not see amazing benefits from languages like ocaml.

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

#44

Post by ori_b »

hobo_mark wrote: post #9

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

The same difficulty,more or less. Mangle in your front-end. The problem comes from the fact that half of C++ lives in headers in the form of templates, so there isn't any code to call, from the perspective of a compiler back end.

To link against code using things like the STL, your compiler would basically need to understand how to compile C++.

Same problem as macros in C, but macros are usually less pervasive in C code, meaning that often you get a good enough binding by ignoring them or filling in wrapper functions by hand.

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

#46

Post by andrewchambers »

Drup wrote: post #19

> 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. :)

Not to mention qbe is much faster than both clang and gcc when it comes to compiling things.

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

#49

Post by nickpsecurity »

andrewchambers wrote: post #43
nickpsecurity wrote: post #12

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

My qbe C frontend is actually written in myrddin which is a lot like rust/ocaml. To be honest, C is not well suited to places where there is adversarial input such as servers, but when it comes to logical correctness of code I do not see amazing benefits from languages like ocaml.

I'd usually ignore the language. Yet, given your interesting resume, there could be some practical decisions and decent code in the compiler worthy of a look in near future. ;) It indeed has some benefits from Ocaml and safer than plain C. So, good work covering that detail.

I'll try to address this, though:

"but when it comes to logical correctness of code I do not see amazing benefits from languages like ocaml."

First, why Ocaml is good for compilers. Most of this is still true and why Rust team used it:

http://flint.cs.yale.edu/cs421/case-for-ml.html

What I can't overstate, already in that link, is how much easier it is to verify the properties of ML languages. They were originally designed to write a theorem prover IIRC. SML had a formal semantics for easier modeling. It allowed for functional programming style that avoids state management issues while (esp Ocaml) still lets you get hands dirty where needed. Modifications for tracking information flow, dependent types, concurrency... all sorts of things were pretty straight-forward. Had a certifying compiler early. Relevant to logical correctness, it's easier to map functional specifications to a ML than a mess like C. This was proven when people doused Leroy et al with praise over first, verified compiler for C because it really was that hard. Likewise seL4 matching functional specs to C kernel code took man-years of effort.

So, languages like C are really hard to get logically correct. Languages like SML/Ocaml are pretty easy to get it done right if you understand the problem. Rarely the language causing your issues. A hybrid like a modified C or Modula that has ML-like advantages without C's disadvantages brings you closer to that ideal while preserving performance & control.

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

#50

Post by riscy »

andrewchambers wrote: post #41
riscy wrote: post #40

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

In llvm you cannot just pass or return structs, every frontend needs to explicitly handle the details of when and how to registerize structs to handle the system V abi for example. That code is not so trivial to do yourself actually.

LLVM supports passing/returning structs (I'm using 3.8.1): https://ghostbin.com/paste/ozsh3

Furthermore, the output does match the System V ABI: https://ghostbin.com/paste/4a5ms

Notice how the struct is placed on the stack and the pointer to it is placed in %rdi for call/return. If you reduce the number of i32's in the struct to 3, the struct's fields are passed via registers since the type fewer than four eightbytes.

My older clang does indeed produce wonky LLVM IR code that seems to try and do this classification in the frontend, so ABI compatibility may have been a problem in the past, but I'm not convinced it's a problem in current versions of LLVM.

Post reply on HN