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

31–40 of 72 posts

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

#31

Post by tinco »

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

Looks good! I know your target is 70% of the performance, but is there any fundamental reason to QBE that it couldn't be more? Suppose I ported my compiler from LLVM to QBE (I think I could do so with not too much effort) would at some point I be able to work on porting some of LLVMs optimizing phases to QBE to get my performance up to par, or is there a design decision you made that will get in the way of the last 30%?

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

#32

Post by mpu »

tinco wrote: post #31
mpu wrote: post #3

Earlier quoted context omitted.

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

Looks good! I know your target is 70% of the performance, but is there any fundamental reason to QBE that it couldn't be more? Suppose I ported my compiler from LLVM to QBE (I think I could do so with not too much effort) would at some point I be able to work on porting some of LLVMs optimizing phases to QBE to get my performance up to par, or is there a design decision you made that will get in the way of the last 3…

It's only a goal I set to myself, if we can do better, heck let's do it! Keeping the code short, on the other hand, is really something I care about.

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

#33

Post by tinco »

mpu wrote: post #32
tinco wrote: post #31

Earlier quoted context omitted.

Looks good! I know your target is 70% of the performance, but is there any fundamental reason to QBE that it couldn't be more? Suppose I ported my compiler from LLVM to QBE (I think I could do so with not too much effort) would at some point I be able to work on porting some of LLVMs optimizing phases to QBE to get my performance up to par, or is there a design decision you made that will get in the way of the last 3…

It's only a goal I set to myself, if we can do better, heck let's do it! Keeping the code short, on the other hand, is really something I care about.

Great, I have the same goal for my compiler. I'd love for the compiler to be able to bootstrap its own backend, and as it only compiles C that would rule out llvm.

I am not sure how far I am along in actually compiling C, if I'd had to guess I'd say around 60%. Hopefully there's not too much crazy things on the horizon.

I'm not a C programmer myself so I first implemented the switch statement in a naieve way, and then I discovered the way they actually work and spent days getting it right.

If I get to the point where I can compile trivial C programs like the benchmarks game, I'll research a move to QBE :)

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

#34

Post by gravypod »

mpu wrote: post #32
tinco wrote: post #31

Earlier quoted context omitted.

Looks good! I know your target is 70% of the performance, but is there any fundamental reason to QBE that it couldn't be more? Suppose I ported my compiler from LLVM to QBE (I think I could do so with not too much effort) would at some point I be able to work on porting some of LLVMs optimizing phases to QBE to get my performance up to par, or is there a design decision you made that will get in the way of the last 3…

It's only a goal I set to myself, if we can do better, heck let's do it! Keeping the code short, on the other hand, is really something I care about.

If you modularize/abstract different optimization passes, you could easily keep code clarity high, while still having a very clean set of code.

I've not done this a lot in C but it looks possible: http://stackoverflow.com/questions/384121/creating-a-module-...

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

#35

Post by wlievens »

tinco wrote: post #30
munin wrote: post #14

Earlier quoted context omitted.

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?

I'm not LLVM expert but usually the answer to that kind of question is aliasing...

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

#36

Post by eatonphil »

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…

Any suggested reading material on writing two implementations side by side like that?

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

#37

Post by eatonphil »

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…

Any suggested reading material on writing two implementations side by side like that?

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

#38

Post by riscy »

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.

> I don't understand what you mean by "fully pruned programs". Maybe you want to refer to pruned SSA form.

The mem2reg pass in LLVM is the recommended method of constructing pruned SSA form. It just implements the standard algorithm.

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

The QBE IL presented to the user is not in SSA form, but internally within your compiler, an SSA representation is kept. I prefer to not have syntactic sugar in my IL.

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

#39

Post by riscy »

tinco wrote: post #30
munin wrote: post #14

Earlier quoted context omitted.

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?

Most casts have zero performance cost and will not interfere with alias analysis. The exception for alias analysis is that inttoptr/ptrtoint is discouraged for address calculation, but the analysis can reason about that. Performance wise, I can see casts between float/int to not be free since they may appear in the final output.

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

#40

Post by riscy »

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.

Post reply on HN