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

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

#21

Post by mpu » Sat, Apr 23, 2016, 5:12 PM UTC

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 take this as a compliment. It means my design choice was totally valid, and maybe even a good one.

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

#22

Post by mpu » Sat, Apr 23, 2016, 5:15 PM UTC

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

At least, I can try!

And also, we are seeing more and more certified C programs: see the DeepSpec NSF expedition grant, the Verified Software Toolchain, and the CertiKOS project for examples. I work with these guys.

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

#23

Post by mpu » Sat, Apr 23, 2016, 5:16 PM UTC

dang wrote: post #11

mpu wrote: post #7

Earlier quoted context omitted.

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!

Cool, thank you guys!

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

#24

Post by danbruc » Sat, Apr 23, 2016, 5:23 PM UTC

QBE [1] is also a query language, Query by Example, developed at about the same time as SQL in the 1970s.

[1] https://en.wikipedia.org/wiki/Query_by_Example

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

#25

Post by munin » Sat, Apr 23, 2016, 5:27 PM UTC

mpu wrote: post #20

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…

> you can simply emit non-ssa form and QBE will fixup things for you

That's exactly what LLVM does though, except the "non-SSA form" involves loads/stores to alloca'd values. The difference is that in LLVM, the language is always in SSA form, it just has some reads / writes to memory that can be pruned, while QBE alternates between being an SSA language and not an SSA language.

LLVM also doesn't "make" you use stack slots. If you wanted to, you could emit fully pruned programs as LLVM IR. Using allocas for variables is a choice that clang makes.

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

#26

Post by azakai » Sat, Apr 23, 2016, 5:28 PM UTC

hobo_mark wrote: post #9

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

It might be interesting to use the clang frontend and modify it to emit QBE instead of LLVM. I believe Visual Studio and ICC do that.

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

#27

Post by azakai » Sat, Apr 23, 2016, 5:29 PM UTC

Any benchmarks of compile times vs other compilers?

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

#28

Post by mpu » Sat, Apr 23, 2016, 5:37 PM UTC

munin wrote: post #25

mpu wrote: post #20

Earlier quoted context omitted.

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…

> you can simply emit non-ssa form and QBE will fixup things for you That's exactly what LLVM does though, except the "non-SSA form" involves loads/stores to alloca'd values. The difference is that in LLVM, the language is always in SSA form, it just has some reads / writes to memory that can be pruned, while QBE alternates between being an SSA language and not an SSA language. LLVM also doesn't "make" you use stack…

I think the extra load/stores clutter the IL.

Also, QBE does not really "alternate" SSA/non-SSA, SSA form is built once at the beginning of the compilation pipeline and preserved later.

I don't understand what you mean by "fully pruned programs". Maybe you want to refer to pruned SSA form. And then, here is my point: with LLVM, either you build SSA yourself or you use allocas. QBE offers a convenient third option.

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

#29

Post by [deleted] » Sat, Apr 23, 2016, 5:54 PM UTC

mpu wrote: post #28

munin wrote: post #25

Earlier quoted context omitted.

> you can simply emit non-ssa form and QBE will fixup things for you That's exactly what LLVM does though, except the "non-SSA form" involves loads/stores to alloca'd values. The difference is that in LLVM, the language is always in SSA form, it just has some reads / writes to memory that can be pruned, while QBE alternates between being an SSA language and not an SSA language. LLVM also doesn't "make" you use stack…

I think the extra load/stores clutter the IL. Also, QBE does not really "alternate" SSA/non-SSA, SSA form is built once at the beginning of the compilation pipeline and preserved later. I don't understand what you mean by "fully pruned programs". Maybe you want to refer to pruned SSA form. And then, here is my point: with LLVM, either you build SSA yourself or you use allocas. QBE offers a convenient third option.

[deleted]

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

#30

Post by tinco » Sat, Apr 23, 2016, 6:03 PM UTC

munin wrote: post #14

jklontz wrote: post #13

Earlier quoted context omitted.

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

Hi Munin, I'm writing a C compiler on LLVM at the moment, and hitting problems with types and pointers, the complexity of which made me think of just using casts everywhere. What is it that makes it expend speed of the generated code? Does it mean certain LLVM optimizer phases won't work anymore?