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

TinyCompiler: A compiler in a week-end

ssloy.github.io

Post reply on HN
Print view View original

81–90 of 120 posts

Re: TinyCompiler: A compiler in a week-end

#81

Post by kragen »

sitkack wrote: post #68
sylware wrote: post #22

On the same way than cproc+QBE I guess, 70% of gcc speed in my benchmarks. The more real-life alternatives to those abominations of gcc and clang, the merrier. I wish the linux kernel devs did care to keep the door _reasonably_ open for such compilers (with assembler source files as alternative to inline assembly, some extensions avoidance and niche expensive compiler features). This is another case of why super comp…

QBE is ... problematic. The source has no comments, single letter variable names. It is not written to be extended by anyone else other than the author. I would recommend libfirm over QBE by at least 10km. https://libfirm.github.io/ https://github.com/libfirm/libfirm

It won't surprise you to learn that I'm always interested in hearing about alternatives to QBE, but from the documentation, libfirm sounds more like a heavyweight alternative to LLVM, not a lightweight alternative to QBE. How big is it?

Re: TinyCompiler: A compiler in a week-end

#82

Post by kragen »

delta_p_delta_x wrote: post #74

Interesting off-topic—I noticed this paragraph: > Personally, I get a twisted pleasure wearing a T-shirt with this print in the 2020s, even though I hate being a walking billboard. But the number of angry comments from confused people makes up for any moral discomfort of advertising on my belly! It's possible the 'angry comments' are from people who may have mistaken it for an antisemitic, white supremacist symbol[1]…

Where is that paragraph?

Re: TinyCompiler: A compiler in a week-end

#83

Post by haqreu »

kragen wrote: post #82
delta_p_delta_x wrote: post #74

Interesting off-topic—I noticed this paragraph: > Personally, I get a twisted pleasure wearing a T-shirt with this print in the 2020s, even though I hate being a walking billboard. But the number of angry comments from confused people makes up for any moral discomfort of advertising on my belly! It's possible the 'angry comments' are from people who may have mistaken it for an antisemitic, white supremacist symbol[1]…

Where is that paragraph?

I removed it, no need to offend people with racial slur, especially when it is not intended.

Re: TinyCompiler: A compiler in a week-end

#85

Post by [deleted] »

delta_p_delta_x wrote: post #74

Interesting off-topic—I noticed this paragraph: > Personally, I get a twisted pleasure wearing a T-shirt with this print in the 2020s, even though I hate being a walking billboard. But the number of angry comments from confused people makes up for any moral discomfort of advertising on my belly! It's possible the 'angry comments' are from people who may have mistaken it for an antisemitic, white supremacist symbol[1]…

[deleted]

Re: TinyCompiler: A compiler in a week-end

#86

Post by haqreu »

contificate wrote: post #76
haqreu wrote: post #73

Earlier quoted context omitted.

Thank you for the reference, I'll check it. Why not fully maximal SSA + DCE? I mean, other than timings consideration. Fully maximal does not even need any graph traversal, it is entirely local to each block.

I think it will introduce too many redundant phis, but I've never used it in practice - so I can only speculate. I'm not convinced DCE will clean maximal SSA up substantially. Even the classic Cytron et al algorithm must be combined with liveness analysis to avoid placing dead phis (that is, it does not produce pruned SSA by default). In the past, there was always a fear that SSA has the potential to cause quadratic…

I'll definitely test maximal SSA + DCE in tinyoptimizer when I'll get to it. For the moment I made [1] somewhat-pruned mem2reg pass, not even sure how to call it. But it indeed required to compute dominance frontiers.

[1] https://ssloy.github.io/tinyoptimizer/mem2reg/

Re: TinyCompiler: A compiler in a week-end

#87

Post by mingodad »

glouwbug wrote: post #2

I appreciate how wonderfully simple and dependency free this is. More often than not people just want to write a compiler of sorts without bison or yacc, or LLVM, and just convert expressions into assembler or vm-like instructions that _just run_. This is a great starting point for that, and I wish I had something like it 10 years ago. (Crenshaw's Let's Build a Compiler is an excellent source too if you want to go on…

But if otherwise anyone want to try with Yacc/Lex I have an online interpreter/editor with more than 250 examples to try/study at https://mingodad.github.io/parsertl-playground/playground/ and just included a grammar for tinycompiler there (select "Tinycompiler parser" from "Examples" then click "Parse" to see a parse tree for the content in "Input source").

Re: TinyCompiler: A compiler in a week-end

#88

Post by sylware »

pjmlp wrote: post #69
sitkack wrote: post #67

Earlier quoted context omitted.

Relativity was discovered by a single guy.

Which confirms complex matters aren't an issue, being able to handle them might be.

wrong, point missed by miles away.

Maybe, "normal"/"average" devs would help you to get the point.

Re: TinyCompiler: A compiler in a week-end

#89

Post by sylware »

sitkack wrote: post #68
sylware wrote: post #22

On the same way than cproc+QBE I guess, 70% of gcc speed in my benchmarks. The more real-life alternatives to those abominations of gcc and clang, the merrier. I wish the linux kernel devs did care to keep the door _reasonably_ open for such compilers (with assembler source files as alternative to inline assembly, some extensions avoidance and niche expensive compiler features). This is another case of why super comp…

QBE is ... problematic. The source has no comments, single letter variable names. It is not written to be extended by anyone else other than the author. I would recommend libfirm over QBE by at least 10km. https://libfirm.github.io/ https://github.com/libfirm/libfirm

Missing RISC-V code generation.

But it is written in plain and simple C99, so it is at least much less toxic than LLVM.

I wonder how cparser (did not check if it was plain and simple C)+libfirm compare in performance to cproc+QBE on my benchmarks. May have to take some time to check that.

Whatever the results, it is always good to have, again, a real life alternative for optimizing C toolchains.

The main issues are the heavy usage of gcc extensions by linux (and glibc, etc).

Re: TinyCompiler: A compiler in a week-end

#90

Post by sylware »

pjmlp wrote: post #60
sylware wrote: post #22

On the same way than cproc+QBE I guess, 70% of gcc speed in my benchmarks. The more real-life alternatives to those abominations of gcc and clang, the merrier. I wish the linux kernel devs did care to keep the door _reasonably_ open for such compilers (with assembler source files as alternative to inline assembly, some extensions avoidance and niche expensive compiler features). This is another case of why super comp…

Circle frontend, that includes all C++17 (when it was current) and the Rust related extensions, was implemented by a single guy.

You mean Circle can output correct intermediate code for the latest gcc code? Or valve mesa aco code?
Post reply on HN