Hi r/Compilers,

I'm on the Intel Graphics Compiler (IGC) backend team. We're hiring compiler interns at both the graduate (Master's/PhD) and undergraduate level. We build the compiler that turns shaders and compute kernels into machine code for Intel GPUs, and the work covers code generation, optimization, and getting the most performance out of the hardware.

If you've ever wanted to work on a production compiler that ships on millions of GPUs, this could be a good fit.

What you'd work on

- Compiler optimization and code generation for Intel GPU architectures

- LLVM-based compiler infrastructure

- Performance analysis and hardware/software co-design

- Real problems with real workloads: your work ships

---

Graduate Intern (Master's or PhD)

Minimum qualifications:

- Currently pursuing a Master's or PhD in CS, CE, EE, or a related field

- Graduate-level coursework in computer architecture and compilers

- Strong C++ programming and software development experience

- Experience with compiler design, optimization, or code generation through research, coursework, or prior internships

Nice to have:

- Experience with LLVM or another compiler infrastructure

- Knowledge of GPU architecture, parallel programming, or performance analysis

- Research or project experience in compiler optimizations, computer architecture, or HW/SW co-design

---

Undergraduate Intern

Minimum qualifications:

- Currently pursuing a Bachelor's in CS, CE, EE, or a related field

- Coursework in computer architecture and compilers

- C++ experience and a solid foundation in data structures and algorithms

- Experience developing and debugging software through coursework or projects

Nice to have:

- Compiler project experience or familiarity with LLVM

- GPU architecture knowledge or parallel programming with SYCL, OpenCL, or CUDA

- Familiarity with Python, Git, and software testing

---

How to apply

Email your resume to hou-jen.ko@intel.com. Use the subject line "[Compiler Intern] Graduate" or "[Compiler Intern] Undergraduate".

It helps to include links to anything compiler-related you've built: a toy compiler, an LLVM pass, upstream patches, a paper, a GitHub repo. We read those closely.

Happy to answer questions in the comments!

Hello r/Compilers,

I would like to share Hike, an open-source, zero-overhead systems programming language implemented in Go with a Go-inspired syntax, targeting both native machines (via LLVM) and WebAssembly.

It is backed by a test suite of over 1,000 compiler tests, proven stable, and is already running in production for commercial software in Japan.

Key Highlights & Motivation

While Go provides great developer productivity, its heavy runtime, garbage collector, and runtime calling conventions make it difficult to embed into ultra-constrained environments, bare-metal microcontrollers, or tiny WebAssembly modules.

Hike bridges this gap: it retains familiar Go-like ergonomics while stripping away the runtime completely.

• Zero-Runtime & Deterministic Footprint: Hike does not rely on a monolithic runtime or a tracing GC. It can emit WebAssembly binaries as small as 2KB. In our stress tests, executing API entry points over 10,000 times resulted in zero memory growth.
• Dual Backend Architecture:
  • LLVM Backend: Produces optimized native code and native objects.
  • Native Wasm/WABT Backend: Directly synthesizes structured WebAssembly (blocks, loops, branches) alongside full DWARF debug information. This enables source-level step debugging directly inside Google Chrome DevTools.
• Extreme Portability (MCU to GPGPU):
  • Targets bare-metal microcontrollers like the Raspberry Pi Pico (RP2040).
  • Architecture designed to support GPGPU compute environments including OpenCL and CUDA.
• High-Throughput / Large-Data Primitives: To support memory-intensive, massive-traffic applications, Hike introduces first-class language constructs:
  • Region/Area memory management for bulk allocations.
  • Threadable & Concurrent variables for explicit, thread-safe data access.
  • mmap-backed variables to operate directly on out-of-core data structures without manual syscall boilerplate.

Compiler Pipeline

The Hike compiler is structured around a High-Level Intermediate Representation (HIR) designed to preserve semantic intent before code generation:

1. Frontend: Lexing, parsing, and type-checking Go-compatible syntax into HIR.
2. Analysis: Escape analysis, ownership tracking, and lifetime inference for deterministic retain/release and region-based allocation.
3. Emitter:
   • Generates clean LLVM IR for heavy machine optimization.
   • Generates clean, structured WebAssembly Text (WAT) preserving natural control flow (block, loop, br) rather than flattening the control flow graph into state-machine dispatchers.

Status & Ecosystem

Hike is actively maintained, stable, and used in production environments. We are also experimenting with cgo-free interoperability (such as embedding Rust-based UI engines like Slint statically into Go using generated .syso objects and Plan 9 ABI bridges).

• Repository: https://github.com/kanryu/hike-lang

I would love to hear feedback, critique, and architectural insights from fellow compiler developers—especially regarding our structured Wasm emission, region memory abstractions, and non-GC systems language design.

Hi there, I've been working on a small systems programming language called CAP. The most interesting part (to me at least) is the compiler itself: it's written in ~pure NASM x86-64 assembly and emits x86-64 machine code directly. No LLVM, no C backend, no libc — the entire toolchain is self-contained.

The language has Python-like syntax (whitespace-sensitive, no fn main()) but no GC — you manage memory explicitly. It supports inline assembly, lists, dicts, and as of a few minutes ago, a native UI toolkit with charting built in (no external libs).

It's very early (v0.1.2), so don't expect a production-ready experience. But the codebase is small enough to read end-to-end if you're curious about how a compiler works at the lowest level.

Repo: https://github.com/Hideyukiakaza/CAP

Happy to answer questions about the architecture or share design decisions.

A few months ago, I shared not-abc, a tiny self-hosting compiler I developed for teaching.

Since then, I've been translating the worksheets and lecturer notes from my undergraduate course Introduction to High Performance Computing into English. The project is now almost complete, with nearly all the teaching material available on GitHub.

The course takes a somewhat unusual approach: students work their way toward building a compiler while simultaneously learning how computers work from the bottom up.

On one side, they explore programming languages, pointers, memory management, parsing, symbol tables, and code generation. On the other, they build logic circuits, an ALU, and a small CPU architecture.

Eventually, these two paths meet.

The compiler they develop targets LLVM IR. The reference compiler is self-hosting and deliberately minimal: it uses only 64-bit values, has no static type system, and supports a small set of built-in functions.

The teaching material includes worksheets, lecturer notes, and hands-on programming exercises. I've taught this course at the University of Ulm, Germany, and I'm making the material freely available for anyone interested in learning or teaching compiler construction.

Repository: https://github.com/michael-lehn/not-abc

One thing I'd particularly like to mention: the feedback I received from this community on my earlier posts has been incredibly valuable. Several suggestions led to concrete improvements in both the compiler and the teaching materials.

Now that the project is approaching completion, I'd love to get another round of feedback before wrapping things up. If you spot anything that could be improved, please let me know!

It's been a pleasure sharing this project here. What a great community!

And of course, if you find the project useful, a GitHub star would be very much appreciated. :)

"I asked Claude to invent a programming language. It invented one called Koppa where changing a single instruction can corrupt every instruction after it."
And the truly satanic part?
It works. It has an interpreter, a compiler, and working example programs.
The language isn't broken. The suffering is by design.
Somewhere, a compiler engineer is about to wake up screaming in hexadecimal.
Koppa (q): Because debugging wasn't painful enough.

I always loved BASIC and CLIPPER 5.3, so I started from an old and never finished BASIC compiler and I asked the AI to improve it adding advanced functions and CLIPPER 5.3 commands, including code-blocks, macro, runtime eval, SAY/GET/READ subsystem. Currently the compiler works on MacOS and Linux. Window version by Visual C++ will come as soon as I will have a laptop with windows installed. I am trying Mingw for windows.

This is an example using macros, eval and code-blocks. It shows also functions passed as parameters of other functions and Sub Main as entry-point.

'FILE: Clipper/ClipperMacroEvalBlocksExtreme.bas

IMPORT ARRAYS

GLOBAL TaxRate AS DOUBLE
GLOBAL cName AS STRING

FUNCTION MkInc() AS FUNCTION(x) AS DOUBLE
    RETURN { |x| RETURN x + 1 }
END FUNCTION

FUNCTION ApplyFn(b AS FUNCTION(x) AS DOUBLE, v AS DOUBLE) AS DOUBLE
    RETURN EVAL(b, v)
END FUNCTION

SUB Main()

    TaxRate = 0.22
    PRINT "=== Clipper macro/EVAL/blocks (extreme) ==="

    'Macro ESPRESSIONE compilata (aritmetica + globale)
    DIM cPrice AS STRING = "100"
    DIM cNet AS STRING = "VAL(cPrice) * (1 + TaxRate)"
    PRINT "net="; &(cNet)                       ' 122

    'Macro VARIABILE: il nome della variabile e' nei dati
    DIM which AS STRING = "TaxRate"
    PRINT "tax="; &which                        ' 0.22

    'Macro COSTANTE che produce un CODE BLOCK (compilato una volta)
    DIM bGross = &("{ |p| RETURN p * (1 + TaxRate) }")
    PRINT "gross(100)="; EVAL(bGross, 100)      ' 122
    PRINT "gross(200)="; EVAL(bGross, 200)      ' 244

    'Macro su VARIABILE con block LETTERALE (espansione compile-time)
    DIM cBlockDef AS STRING = "{ |p| RETURN p * (1 + TaxRate) }"
    DIM bVar = &(cBlockDef)
    PRINT "vargross(150)="; EVAL(bVar, 150)     ' 183

    'Code block letterale + EVAL multi-argomento
    DIM bArea = { |w, h| RETURN w * h }
    PRINT "area="; EVAL(bArea, 6, 7)            ' 42

    'Block con concat: risultato stringa + param usato solo in concat
    DIM bBang = { |s| RETURN UPPER(s) + "!" }
    PRINT "bang="; EVAL(bBang, "x")             ' X!
    DIM bRaw = { |s| RETURN s + "!" }
    PRINT "raw="; EVAL(bRaw, "x")               ' x!

    'Block applicato a tutti gli elementi di un array (AEVAL: elemento, indice)
    DIM prices = {100, 200, 300}
    AEVAL prices, { |v, i| PRINT "  gross["; i; "]="; v * (1 + TaxRate) }   ' 122 244 366

    'Nested Macros
    DIM cThree AS STRING = "deep!"
    DIM cTwo AS STRING = "cThree"
    DIM cOne AS STRING = "&cTwo"
    PRINT "nested="; &cOne                       ' deep!
    'EVAL stringa (GMBasic) come COMANDO + text substitution (globale)
    EVAL("TaxRate = 0.10")
    PRINT "tax2="; &("TaxRate")                  ' 0.1
    cName = "world"
    PRINT "subst=Hello &cName!"     ' Hello world!  (globale espanso)

    'EVAL con block INLINE + block restituito da funzione
    PRINT "inline="; EVAL({ |s| RETURN UPPER(s) + "!" }, "x")   ' X!
    PRINT "fromfn="; EVAL(MkInc(), 5)                           ' 6
    DIM bm = MkInc()
    PRINT "infvar="; EVAL(bm, 5)                                ' 6
    EVAL({ |s| PRINT "stmt="; s }, "y")                         ' stmt=y

    'Closure: EVAL annidato + function-value catturato + param FUNCTION
    PRINT "nested="; EVAL({ |x| RETURN EVAL({ |y| RETURN y + 1 }, x) }, 5)  ' 6
    DIM inner = { |y| RETURN y + 1 }
    DIM outer = { |x| RETURN EVAL(inner, x) }
    PRINT "capt="; EVAL(outer, 5)                               ' 6
    PRINT "param="; ApplyFn({ |z| RETURN z * 2 }, 21)           ' 42
    PRINT "Clipper macro/EVAL/blocks: fatto."

END SUB

The compiler supports graphics by SDL, Vulkan, Game Loop (thousands of fluid sprites), TUI, Windows Manager, DBF files with memo field (DBIII/DBIV/Clipper/FoxPro), TBROWSE, ISAM, RDD system, SQL (SQLite/DuckDB integrated), REPL, Package Manager (like cargo/pip/modules), and more.

The compiler supports also numbered lines, GOTO, GOSUB, ON ERROR, ON KEY, etc.

This an attempt to bring old clipper/basic programmers into a modern world, saving their old code.

Will you try it if will be made open source and what do you think about it?

PRISM is a C and C++ compiler written in JavaScript, targeting JavaScript (not Wasm): one JS function per C function, run by the engine's JIT. Its purpose is to compile unmodified real-world code (MAME, Quake I–III, ScummVM, Lua, SQLite, PuTTY) and run it in a browser.

Disclosure up front: the code was written with Claude Code (Anthropic's coding agent) under my direction. Because of that, the whole project is built around not trusting it: every claim is checked by a gate against an independent implementation, and each gate carries a deliberate mutation it must catch.

Some design points that might interest this sub:

- Two exact ABIs: i386 System V and 16-bit real-mode DOS (small/medium/large, far/huge pointers). Struct layout is held to gcc 12 i386 on ~105,000 generated checks, bitfields included.

- Preprocessor token-identical to gcc -E, including 289 whole translation units.

- C++98 subset lowered to C (classes, virtual and multiple inheritance, templates, exceptions on setjmp/longjmp), enough for ScummVM and Enemy Territory.

- Assembly translated, not emulated: Borland inline asm, TASM modules, Watcom #pragma aux, NASM.

- Testing: c-testsuite and gcc.c-torture/execute with 0 wrong answers (a construct it can't compile is a named refusal, never a silent miscompile), csmith against gcc -O0/-O2, and whole programs bit-identical to native builds (MAME 0.34: 15/15 games over 1,500 frames).

- Deterministic: fixed __DATE__, a virtual clock when headless, so every comparison is exact and re-checkable.

A small example of what exact comparison turns up: on one float-only Rosetta Code program, x87 gcc, SSE gcc, clang (which fuses a*b+c into an FMA by default) and PRISM gave three different characters for one pixel; PRISM matched SSE gcc and -ffloat-store, i.e. IEEE single precision rounded per operation.

No optimiser yet: about 9.5× slower than clang -O2 on a Z80-core benchmark.

You can type C or C++ in the page and see the emitted JS: https://prism-compiler.pages.dev/web/live/

Source (MIT): https://github.com/jfrelat-lab/prism

The Flux compiler is now written in Flux.

This means the Python version of the compiler is now officially retired.

There’s still a long way to go till all components are translated and implemented, but progress is being made daily.

The package manager will also be capable of publishing soon as well.

Features such as the FVM and comptime will be held off until a significant portion of our own x86-64 backend is completed.

The borrow checker is next on the line for translation, and will also come with additional improvements.

We would love to hear some feedback about what you’d like to see added to the ecosystem next! Do you think the stdlib should be expanded, or shocked existing tooling be the focus?

Hi all,

I have created a proof of concept that uses LLM agent to suggest performance at runtime. It proposes compiler directives based on JEP 165. These directives are then ingested by C2 to create optimized code.

Here is the link to full blog post: https://chains.proj.kth.se/llm-jit-agent/

Looking forward to a nice discussion here :)

I've been developing the statically typed scripting language Umka for 6+ years. The limitations of reference counting used in Umka 1.x have become so obvious that replacing it with a mark-and-sweep garbage collector is now the key change made to the upcoming Umka 2.0.

The interpreter architecture has got cleaner. With many ad hoc fixes and workarounds having become redundant, the codebase is now 10% smaller. Freeing reference cycles is no longer a problem, so the weak pointers, arguably the most counterintuitive feature in a simple scripting language, are deprecated. It shouldn't be the user's responsibility to avoid memory leaks: the less the cognitive burden, the more attractive the language for a novice.

As Umka is used in the Tophat 2D game framework, I measured the impact of this change on rendering performance in my Hover! maze demo in "strabismic" mode, with two overlapping scenes rendered independently from different view angles. It would take 28 ms per frame with reference counting vs. only 22 ms (including 4 ms for garbage collection) with mark-and-sweep. I forced garbage collection at the end of each frame, but could have done it much less frequently to save more time.

Theory suggests that the average CPU time spent on reference counting and mark-and-sweep should be roughly equal. However, the redundant reference counting instructions injected into Umka 1.x bytecode to ensure memory safety in rare edge cases cost a lot.

Surprisingly, the most intricate part of this transition to mark-and-sweep was escape analysis that prevents pointers to local variables from escaping the function stack frame after the function returns. It eventually required a kind of rudimentary reference counting targeted specifically at escaping references. These reference counts are touched much less often, only on detecting escape suspects, so they don't affect performance, except some contrived examples. Hope I'll be able to come up with an even better solution by the Umka 2.0 release.

I've been developing AutomataLab, a desktop application for exploring formal languages and computational models.

Its Parser Studio supports LL(1), LR(0), SLR(1), CLR(1), LALR(1), CYK, and Earley parsing, with visualizations of parse tables, LR item sets, and parsing steps.

It also includes:

• Machine Studio: Interactive simulations of finite automata, PDAs, and Turing machines.
• Grammar Lab: Grammar analysis, classification, derivations, and transformations.
• Conversions: Transformations between supported computational models and formal representations.

Built with Tauri, React, TypeScript, and Rust, the goal is to make theoretical concepts easier to explore and understand.

GitHub: https://github.com/reeshavsinha/AutomataLab
Website: https://automata-lab-one.vercel.app

I'd appreciate feedback, especially on the parser implementations, visualizations, and features useful for compiler construction.

Note: The Windows build may show a Microsoft Defender SmartScreen warning because the application is not code-signed. Please verify downloads through the official GitHub repository.

Something new about my runtime 🐱.

With NaN boxing, x = 1.5 and y = float("1.5") are the same 64 bits. CPython says x is y is False, and there is no room left in the value to tell them apart.

Edge's design treats identity as history instead of bits. SSA already gives every definition its own number, so is just compares versions at compile time.

If the value went through the heap, the VM is deterministic, so it replays that stretch once and records where each value came from.

Normal code pays nothing for this optimization.

Right now I'm working on the next big challenge, inferring a few of types with RVSDG and compiling Python to LLVM to get close to C speed.

I work since a while on gb2swf, a static recompiler that takes Game Boy (SM83) machine code and turns it into Haxe, which then compiles to a Flash SWF that runs in Ruffle. Yes, Flash. But the part that fits this sub is the recompiler so thats what this post is about

The classic problem with static recompilation of old console code is that you dont know what is code and what is data, and you dont know all jump targets (jp hl, jump tables). So I dont try to find it statically. The ROM first runs on an interpreter in Node.js, once without input and four times with random button presses, 6000 frames each, and it records every executed instruction and every jump target. Only blocks that were actually seen get recompiled.

Codegen: every basic block becomes Haxe with the SM83 registers as local variables. Blocks are grouped into functions, so one block flows into the next without going back through a dispatch loop. The original instruction stays as a comment above each generated line so the output is still readable.

The verification is the part I would like feedback on. The game runs on the interpreter and on the recompiled code side by side with three input sequences, one of them the profiler never saw. At every block entry the registers and the cycle count have to match, and every frame has to match. If a block diverges it goes back to the interpreter and the check runs again, so a mismatch never ends up in the output. Code the profiler never reached also stays on the interpreter, the game always runs, unseen paths are just slower.

Interpreter and recompiler are both generated from one description of the instruction set so they cant drift apart. Memory accesses happen on the correct cycle inside each instruction, otherwise the cycle check would mean nothing.

Numbers on 7 open licensed homebrew games (M1, Ruffle in headless Chrome, input the profiler hadnt seen): 79 to 98% of executed instructions run as recompiled code, and a frame takes 6 to 11 ms of the 16.7 ms budget.

What still bothers me:

- the 2 to 21% that stays interpreted is mostly code behind rare input. You can record your own play and feed it back with `gb2swf --record`, on itself that works but its not really a solution

- lockstep only proves the two are equal on the inputs I tried, nothing more

Did someone here do something like this for another ISA? Mostly curious how you handled coverage, is there something smarter then random button mashing...

I made this, its MIT and the repo is public on the Burg Media github (no ROMs included ofcourse)

I've published tvm-recover, a Tencent VM devirtualizer built around a recovery frontend and an LLVM reconstruction backend.

The compiler angle is what I wanted to share here: the input is a protected binary rather than source code. The frontend follows VM handlers, tracks guest register and memory effects, simplifies expressions algebraically, and reconstructs control flow. It emits a guest-level listing that the backend translates into LLVM IR and compiles into native analysis code.

The pipeline looks like this:

Protected PE → semantic recovery → guest IR → LLVM IR → native payload → patched PE

The repository includes an interpreter and a differential harness for comparing the compiled payload against the listing interpreter, plus PE/PDB tooling for inspecting the result in conventional reverse-engineering tools.

It's still a prototype, with known semantic issues being worked through. Differential agreement checks the backend against the interpreter; it doesn't independently prove equivalence to the original binary.

I'd especially welcome feedback on the boundary between the recovery IR and LLVM, and on testing a compiler pipeline whose frontend starts from obfuscated machine code.

Code and screenshots: https://github.com/NeuroSaki987/tvm-recover

I benchmarked all three languages with their standard commands and the standard scripts without any made optimizations in the scripts.

The benchmark is Compile, Run, and Size.

Hello, World!:

Language - Compile - Run - Size

C (GCC 13.3) - 35.5 ms - 2.3 ms - 15,960 bytes

NASM 2.16 with LD - 6.4 ms - 1.5 ms - 8,864 bytes

COMPRINLY 1.3.2 - 9.6 ms - 1.5 ms - 274 bytes (Old version was 290 bytes)

Count primes below 300,000:

Language - Compile - Run - Size

C (GCC 13.3) - 38.6 ms - 50.2 ms - 15,960 bytes

NASM 2.16 with LD - 6.6 ms - 48.4 ms - 5,032 bytes

COMPRINLY 1.3.2 - 10.7 ms - 48.4 ms - 361 bytes

You could test Comprinly for this if you doubt the benchmark, I have no testers.

Overall:

Compile Speed - NASM

Run Speed - NASM and Comprinly

Size - Comprinly

You can try Comprinly in the linked repo

Hi,

I’m working on a compiler at my company that generates Java code represented as a custom AST, then uses ASM to produce JVM bytecode.

I’d like to apply optimizations to this AST, or convert it to a standard AST representation if needed. Are there any libraries that support optimizations such as constant folding, dead code elimination, and factoring out duplicated code?

As an alternative, I’m considering targeting LLVM IR, although this would introduce other challenges, particularly around memory sharing and interoperability with the JVM. Do you know of any libraries or tools that can translate Java code or JVM bytecode into LLVM IR?

I see abusing the use of AI just to build a pathetic compiler as more of being main character and ego s** in Reddit than learning in my opinion

That's not fun anymore, it's sad

Hey guys,

Been working on a custom systems language called Tridentix for a while now, and just published the initial v0.1.0 code on GitHub.

It's built with Rust, has a custom hand-written lexer/parser frontend, targets LLVM, and comes with Docker support for testing. Added the design specs and initial codebase in the repo.

Would love some honest feedback on the VM specs and compiler structure from fellow language dev folks. Thanks!