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!

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.

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.

"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.