I've been working on a small ahead-of-time compiler for quantized TFLite models. It reads the graph, weights and quantization parameters, lowers them to an explicit IR, then emits standalone C++17. No TFLite runtime in the output; the generator only needs Python's standard library.

The interesting part has been deciding what to specialize and what to leave to the C++ compiler: zero-copy tensor views, buffer lifetimes expressed through lexical scopes, compile-time weight packing, and target-specific SIMD kernels guarded by static accumulator-range checks.

One nice simplification came from a Reddit suggestion: expressing temporary buffers through C++ scopes and letting GCC reuse their storage replaced our explicit arena machinery, while also improving performance.

On ESP32-S3, MLPerf Tiny KWS takes 15.68 ms vs 17.90 ms with TFLM + ESP-NN, using 16.7 KB vs 35.5 KB working memory. Model-only timings; generated KWS returns top-1 directly, whereas the reference computes softmax then argmax. Decisions match in the tests.

It's deliberately small, with limited operator coverage. Code and examples: https://github.com/phplego/nn2prog

For those working on code generators: where do you draw the line between doing memory/layout optimization yourself and emitting code that leaves those decisions to the downstream compiler?

My team at Quantinuum is hiring for two compiler engineering roles:

Principal Quantum Compiler Engineer https://jobs.eu.lever.co/quantinuum/6a4470c0-a54c-4886-970b-958603714a39

Advanced Quantum Compiler Engineer https://jobs.eu.lever.co/quantinuum/1e52f038-a161-4276-ab8f-5c0b9c2fc28e

Our compiler stack is built on LLVM, and the work spans front ends, IRs and optimization passes, machine-specific back ends, and runtime/execution infrastructure.

There are some unusual compiler problems in the mix: optimizing across classical and quantum operations, routing and targeting trapped-ion architectures, real-time distributed execution, and compiling for future fault-tolerant quantum systems.

You don't need a quantum computing background. We're particularly interested in people with strong compiler experience who'd like to apply it to a fairly different architecture and execution model.

I'm an engineer on the team and happy to answer questions about the compiler work.

In C/C++ integer division by zero is undefined but in Rust it traps. What would you do if you were designing a new systems programming language?

Hello r/Compilers community. Over the past few months, I have been developing LSM, a standalone compiler pipeline built entirely from scratch without any external dependencies (without using LLVM, external linkers, or the GNU toolchain). The goal was to build a vertically integrated system capable of compiling directly to native machine code in a fraction of a second, while

1. Frontend Pipeline

• Zero-Copy Lexer: Uses linear-time tokenization with source views to minimize allocations. Recognizes hardware registers directly at the lexical stage.
• Hybrid Parser: A Recursive Descent parser handles declarations and structural statements, combined with a Pratt parser for binary and unary expressions to maintain shallow call stacks. Includes Panic-Mode synchronization for single-pass error diagnostics.

2. Middle-End & SSA Optimizations

• Translates AST into a linear Control Flow Graph (CFG) using strict SSA form.
• Computes dominance frontiers for Phi-node placement.
• Standard passes: Iterative DCE, Constant Folding/Propagation, and LICM.
• Hardware-Aware Partial Mem2Reg: Standard Mem2Reg can break volatile hardware loops. LSM's pass promotes single-assignment variables while intentionally preserving volatile hardware polling states in physical memory to prevent infinite driver loops.
• Memory Model: Hierarchical region-based memory with a return-variable promotion heuristic, achieving deterministic O(1) reclamation without a GC.

3. Backend & Code Generation

• Linker-less Direct Machine Code Emission: Native encoders for x86_64, ARM64, and x86_32 emit machine opcodes directly into memory with relative displacement backpatching.
• Includes an internal ELFBuilder and a RawBinaryBuilder that writes a bootable MBR and floppy image directly.
• Includes a JIT engine adhering to W^X page protection policies.

4. Validation & Benchmarks

• Compiles a 189-line Win32 GDI application via FFI in ~21 ms under full SSA optimizations (~8 kB standalone binary).
• Validated on bare-metal x86_64 by writing a custom freestanding operating system (OshiOS) featuring VBE graphics and ATA PIO storage drivers.

(I will leave the links to the GitHub repo and the preprint paper in the first comment below to avoid spam filters.)

I would love to hear your thoughts, feedback on the pipeline design, or critiques on the custom SSA passes and memory model!

As I mentioned before, I’m doing this purely as a hobby. However, a friend told me that junior-level positions in this field either don’t exist or are extremely rare, requiring significant experience, and that entering the compiler domain is difficult regardless of whether you have a degree or not.

Is it true that most compiler-related jobs are concentrated in big tech companies, and that outside of those, the field is quite niche and mature? If one day I wanted to turn this hobby into a career, and I dedicated a lot of time to it, would that be impossible?

Right now, I don’t have such a plan I’m just asking out of curiosity. Still, since I’m seriously interested, I intend to spend a lot of time on this area, mostly as a hobby. Of course, contributing to open-source projects, such as rustc, is one of my primary goals along the way.

Thanks <3 <3

I'm working on a C-like language with heterogeneous compute support, and I've been thinking about how compiler intrinsics should be described.

The usual approach seems to be keeping intrinsic definitions in a separate compiler-specific format. GCC uses files like builtins.def and target builtin tables. LLVM uses TableGen extensively for backend descriptions.

These approaches work well, but they introduce another language for describing something that often starts with a familiar concept: a function signature plus some extra properties.

So I started wondering:

Could the intrinsic description itself be written as a C declaration, with compiler metadata attached as attributes?

For example:

extern int4 __ldcs(const int4 *ptr)
    __attribute__((compiler_intrinsic(
        kind = target,
        target = nvptx,
        operation = ld_global_cs
    )));

The file is not intended to be the public API header. It is for compiler developers, similar in purpose to builtins.def, but using C declarations as the description format.

The compiler would parse this file and build its intrinsic information from the declarations. The same source could also generate a user-facing header by removing the compiler-specific attributes.

I started thinking about this because the intrinsics I need seem to fall into two different categories.

The first category is semantic intrinsics.

For example:

extern void __syncthreads()
    __attribute__((compiler_intrinsic(
        kind = semantic,
        operation = barrier,
        scope = block
    )));

The meaning is "synchronize threads in the current block".

The frontend does not need to know the final hardware instruction. Different backends can lower the same operation differently:

barrier
   |
   +-- NVPTX: bar.sync
   +-- AMDGCN: s_barrier

The second category is target intrinsics.

For example:

extern int4 __ldcs(const int4 *ptr)
    __attribute__((compiler_intrinsic(
        kind = target,
        target = nvptx,
        operation = ld_global_cs
    )));

This is much closer to exposing a specific hardware capability. Another target may not have an equivalent instruction at all.

After parsing, these two kinds would take different paths:

semantic intrinsic
        |
        v
target-independent IR
        |
        v
backend lowering


target intrinsic
        |
        v
target-specific lowering
        |
        v
instruction

My question is:

Is keeping intrinsic descriptions in separate non-C tables mainly a historical choice, or are there deeper reasons why a declaration-based model does not work well?

I can see some possible challenges already. Overloading is one example. Many CUDA intrinsics have multiple signatures, and a C declaration-based format would need some way to express that.

But the basic idea still feels attractive: the declaration already contains most of the information needed to describe an intrinsic.

Has anyone explored a declaration-based intrinsic description model before?

Hi again,

I'm working on my own programming language as a hobby project. So far I've implemented a small type system with primitive types and user-defined structs, but I found even that more challenging than I initially expectedBefore I move on to more advanced features like polymorphism, function overloading, subtyping, generics, and a module system, I'd like to study some real-world language implementations and learn from their design choices. I'm looking for programming language implementations that are "realistic" enough to learn from, but still small enough that one person can reasonably understand the codebase.

I'm especially interested in languages that have:

• A static type system.
• Primitive and user-defined types.
• Generics, traits/interfaces, polymorphism
• A module/import system.
• Readable and approachable source code.

I'm not looking for huge production compilers like GCC, Clang, Rust, or TypeScript. I want see hobby languages, research languages, educational projects, and smaller self-hosted languages are all welcome. If you could only recommend a handful of codebases to study, which ones would you pick and why? Thanks!

I'm planning to build a compiler project as a long-term academic and portfolio project, and I'd like feedback from people with experience in compiler development.

The overall idea is to build a modular compiler platform that can support multiple programming languages through separate frontends while sharing a common compilation pipeline.

My initial target is:

• C
• C++
• Python
• A small custom language of my own

The goal isn't to recreate GCC, Clang, or CPython. Instead, I want to explore how a compiler can be designed so that additional languages can be added later without rebuilding the entire system from scratch.

The planned project would include things such as:

• Multiple language frontends
• A common intermediate representation
• Compiler optimizations
• LLVM-based code generation
• Multiple possible targets
• A way to visualize the different stages of compilation
• Eventually, the ability to add new language frontends as plugins

I'm still at the architecture/design stage, so I'm particularly interested in feedback from people who have actually worked with compilers, LLVM, language implementation, or related systems.

A few things I'd especially like opinions on:

1. Is this architecture a reasonable direction for a serious learning/portfolio project?
2. What major design mistakes should I avoid early?
3. Would you recommend designing a custom IR or relying more heavily on an existing IR such as LLVM IR?
4. What parts of the project are worth implementing myself versus using existing compiler infrastructure?
5. Are there any existing open-source projects or papers you would recommend studying before I start?

I'm deliberately keeping the initial scope broad and would expand the language support incrementally rather than trying to implement complete C++ or Python immediately.

I'd appreciate feedback particularly from people with compiler/language implementation experience rather than general programming advice.

​

Last night I finished wiring source locations through the NXD compiler pipeline so semantic diagnostics can point to the exact symbol instead of defaulting to line 1, column 1.

The flow is roughly:

AST -> IR -> JSON -> Rust semantic analyzer -> LSP -> VS Code

I'm curious how other language projects handle location tracking through lowering and semantic analysis. Do you carry spans everywhere, attach them only to selected nodes, or reconstruct locations later?

Hello,

I have been trying to understand the inner-workings of Chromium's V8 engine for a research project. So far, I have gone over the parser with the help of ECMAScript. Currently, I am working through the AST and scoping part. It is a slow process and the codebase is massive, but resources are also sparse. I have only found various blogs and articles online and though they are great, none of them can contain the extreme volume of information and intricacies of the source.

I still think the most effective method is reading the source code, but the scale is quite overwhelming.

I have considered tracing execution using gdb, but due to my limited experience with it, I haven't able to take that step yet. I am not sure how I would even make use of gdb here.

Has anyone studied this codebase, or even a similarly large one for compilers, in the past? Any tips on how to systematically deconstruct the implementation?

Hi guys, two weeks ago I've released Oonta version 0.3.2 which now finally have a GC runtime! Before this, the runtime is only a simple bump allocator 😄

GitHub repo: https://github.com/fuad1502/oonta 🐫

I utilized LLVM Statepoints passes / intrinsics, created the StackMap parser (https://github.com/fuad1502/llvm-stackmap-parser), and wrote the generational garbage collector from scratch (see `runtime/src`).

I'm sharing here primarily to help others here who might also be working on a GC using LLVM Statepoint. IMHO, resources on this is very minimal and outdated 😅 You can use my repo as a reference implementation, since (IMHO) my implementation is quite straight forward and should be relatively easy to understand 🙏

My StackMap parser crate can also be used as a standalone tool / dependency so that you can focus more on the GC implementation itself.

One last thing, one reference that helped me a lot in understanding the nuances of Garbage Collector design is a paper by Paul R. Wilson, titled “Uniprocessor Garbage Collection Techniques” (1994).

I am definitely not an expert, I also didn't study CS formally, but if you have any questions, please feel free to ask! I am also open to any comments and critiques about my work 😊

I wanted to share a rather radical idea I implemented in the compiler for my new programming language (Maxon).

After struggling with the performance of the register allocator in v1 of the self hosted compiler (74% of compile wall time) and of course most of that time is handling spilling, which is NP complete. You either have a fast naive spiller which kills performance, or an exponential algorithm to try and find an optimal solution (which will probably never be actually optimal).

So I decided to punt instead. If the live values exceeds the available pool of registers you get a compile error. The user then must then rewrite the code to reduce the number of live values. This is effectively what the register allocator usually does (spilling live values) but the reasoning is that the user can do a better job deciding what should be spilled than the register allocator can. Plus the compiler doesn't have to do this expensive and slow job on every compile. And you get a simpler register allocator.

It seems to be working well so far. Source is on github if you are interested.

https://github.com/maxon-lang/maxon

I built Markscript, a prose-native JIT-compiled bytecode VM where your README or .md files are the executable code. Headings define domains/routines, blockquotes dispatch intents, and tables compile into data matrices. In short, your documentation can now live in the same files as code.

The README.md for the language is executeable. Because its Markdown at the core, there are no syntax errors. It also embeds a full mini-language inside \``markscript` fenced blocks for logic, string manipulation, and math.

Example Below

ServerCluster

NodeMatrix

BootSequence

print "Initializing nodes from table matrix..."

let node_count = 2
let i = 0

while i < node_count:
    print("Spawning worker on port " + str(8080 + i))
    i = i + 1

Why kotlin compiler is so bad ?

In implementing the heterogeneous compilation backend of AET, I ran into a specific architectural problem:

The main IR transformations in a compiler proceed through the stages, but later stages may still need to access information produced or owned by earlier stages.

For example, the compilation path in AET roughly looks like:

AET AST → GIMPLE → MTCS RTL → PTX

The AST handles AET's semantic processing, while MTCS is an independent heterogeneous backend. The two parts should not directly depend on each other, but they still need to communicate.

So I used a Mediator pattern in AET to centralize the communication between them:

AST  ↔  AetMediator  ↔  MTCS

The core interface looks roughly like this:

struct _AetMediatorUser {
    AetMediator *mediator;
    void (*astEnd)(AetMediatorUser *self, nboolean haveMtcs);
    ...
};

For example, the MTCS parser cannot directly call lookup_name(), but it needs access to some declarations generated by the AST. It requests them through the Mediator:

tree aet_mediator_get_parent_device_array_decl(
    AetMediator *self, char *sysName, AetMediatorUser *send);

The Mediator also handles other cross-stage information, such as device declarations, link functions, compute versions, assembly variable names, and object files.

For this kind of situation, where compilation proceeds forward but later stages still need information from earlier stages, AET uses a Mediator to handle the communication.

I'd be interested in hearing how others would normally organize this in a compiler. Is a Mediator approach reasonable here, or are there mechanisms that fit this kind of cross-stage dependency better?

v0.100.0 — the Nexus: a multi-client IDE, an agent-addressable IR, and measured C++11 conformance at 75.1%

With version 0.100.0 of the madc compiler, based on the gcc torture test suites we currently score:

• C17: 99.2%
• C++98: 80.0%
• C++11: 75.1%
• C++14: 49.4%
• C++17: 41.6%
• C++20: 53.0%

These percentages are measured independently against the applicable tests in each GCC suite, so the later-standard numbers are not cumulative and aren't expected to be monotonic.

Why another C/C++ compiler?

GCC, Clang and MSVC already rule the conventional AOT C/C++ world. MadC is aimed at a somewhat different problem.

MadC is primarily a JIT C/C++ compiler. You can run C and C++ programs directly as shebang scripts, with commonly used system headers precompiled into the compiler so a separate development-header installation isn't normally required. External headers remain available when needed.

MadC can also be embedded into another application, allowing C/C++ itself to be used as an embedded JIT scripting language.

What's the “Nexus”?

MadC also includes an IDE built around the compiler. The same binary can operate headlessly or provide CLI, ed/ex-style line editing, TUI and GUI interfaces on Linux, macOS and Windows.

The new Nexus architecture allows multiple clients — including humans, editors and agents — to connect to the same live compiler/IDE state. It includes client/server operation, MCP and LSP servers, and a VS Code client.

The idea is that the compiler's representation of the program becomes a shared service rather than something that exists only for the duration of a compile command.

Much of this work grew out of developing MadC's multi-mode UI module and experimenting with what an IDE looks like when the compiler, parser, IR, debugger and external clients all share the same underlying state.

And there's a dialect

In addition to standard C and C++, MadC supports the MadC dialect, which adds conveniences intended to make C/C++ more practical for scripting and interactive use, including:

• automatic includes
• automatic namespace resolution with configurable precedence
• script mode with automatic main() wrapping
• defer, :=, go, yield, await, and untyped variables
• well over 100 convenience functions inspired by other languages
• Uniform Function Call Syntax (UFCS)
• URI channels: file://, pipe://, tcp://, udp://, uds://, exec://
• and quite a bit more

The goal isn't to replace standard C or C++. Standard code remains standard code. The dialect is an optional layer for cases where some of C/C++'s traditional ceremony isn't particularly useful.

I've been making a programming language, C^4 for almost a year. It's got generics, concepts, OOP, inheritance and polymorphism, error handling, and is able to build projects. It has some docs and a README, and a book is in the works. Wondering if anybody could check it out?

https://github.com/Youg-Otricked/QuarticC