This is Reid Kleckner’s personal blog. My goal for this site is to try to share my thoughts about compilers, open source development, systems programming, and other topics. The act of listing my accomplishments feels like self-aggrandizement, but I think I’ve reached a point in my life and my career that I’ve done several things that I can be proud of, detailed below. Given where I’ve been and what I’ve done, I think I have some unique perspectives to share. I want to put those ideas out there, and try to contribute to the “small web”.

What follows is basically an editorialized resume.

MIT Graduate (2006-2011)#

I graduated with a Bachelor’s in CS in 2010 and a masters at the end of 2011. MIT is an amazing place! My favoriate and most memorable classes were:

  • 6.035: The compiler course.
  • 6.828: The operating systems course.
  • 6.172: Performance engineering. I TA’d this course during 2011 with John Dong.
  • 6.851: Advanced data structures

When I started MIT, Python was my favorite programming language, but when I left, I was a C/C++ programmer, who cared about page tables, cache hierarchies, parallel programming, and other systems programming concepts.

Unladen Swallow (2009)#

My second Google internship focused on Unladen Swallow, which was a fork of CPython with an LLVM-based JIT. This was my first introduction to LLVM and C++, and I learned a lot. I was the intern, and my project was supposed to have to do with fixing backtraces in gdb, and I did eventually get a patch merged to gdb, mostly because the amazing Paul Pluzhnikov held my hand most of the way through. I don’t think I’ll offend my former colleagues by saying that none of us had prior experience building JITs of VMs for dynamic languages, so it’s not surprising that ths project didn’t succeed. I posted a retrospective on it back on blogspot in 2011, which is now a Wikipedia foot note, so that’s cool. :) Regardless, this was a great learning experience.

Contributed to DynamoRIO and Dr. Memory (2009-2013)#

DynamoRIO is a high-performance dynamic binary instrumentation framework, which I encountered when I joined Saman Amarasinghe’s research group at MIT, COMMIT.

My master’s thesis was about inlining instrumentation machine code directly into the translated code stream, and avoiding the overhead of context switching over to the clean stack maintained for instrumentation tools. This was extremely challenging, and I don’t think I contributed meaningfully to the state of the art, but I certainly learned a lot about x86, machine code, reachability, signals, stacks, register contexts, etc etc.

After this, my first role at Google was applying my skills with DynamoRIO to Dr. Memory, an instrumentation tool similar to Valgrind Memcheck. Chrome took security vulnerabilities very seriously, and Valgrind was simply too slow for fuzzing or to run Chrome’s entire test suite. Dr. Memory also ran on Windows, the primary platform of interest. However, as soon as I joined, it quickly became clear that Address Sanitizer was a better fit for Chrome’s needs. If you can recompile your entire application, you can do dynamic program analysis with ~2x overhead instead of the >~10+x cost imposed by software code cache tools like Valgrind and DynamoRIO. So, I did the logical thing, which was to switch to the winning tool, and I joined the LLVM team focused on bringing Clang to Windows.

Lead the Chromium Toolchain Team (2013-2020)#

The short term goal of this project was to get Clang on Windows so we could run ASan. That was our incremental, progressive rollout target. After that, the goal was to surpass MSVC in quality metrics and provide Chrome with a uniform, single portable toolchain for all desktop and mobile platforms, which was sort of Nico and Hans’s vision after doing the original Chrome Clang Mac port. Chrome was competing with Firefox, which meant it had to be portable, it was how Google would bring its web properties to the user, whereever they were.

Joining the Lexan team was a truly amazing opportunity, and I think Chandler managed to pull together an extremely talented group of people for this project:

  • Timur Ishkhodzhanov: Ported ASan to Windows, got Chrome frankenbuild working through compiler fallback (run clang.exe, retry with cl.exe if clang fails).
  • Rui Ueyama, who went on to write LLD/COFF, contribute to the ELF port, and go on to mold.
  • Hans Wennborg: Expert debugger, long time LLVM release manager, talented and methodical guy. Hans was a generalist, but he specifically nailed down all the dllexport / dllimport corner cases.
  • David Majnemer: Joined early, and I would’ve utterly failed to Windows exception handling without his assistance. He went on to be the lead for XLA, and I’m probably understating his contributions there. We copresented a speech on WinEH.
  • Zachary Turner: Did a ton of LLDB Windows work before pivoting to LLD PDB support, then going to Roblox, where I think he’s doing great.
  • Jeff Bailey: Helped us run meetings, write OKRs, project manage, before I learned how to do that.
  • Me: Eventually I became the TL, and I did whatever was necessary: musttail, vtable thunks, SEH, Windows exception handling, inalloca, basically all the truly godforesaken ABI features. #pragma comment lib, etc.
  • Nico Weber: Chrome liason, generalist.

I apologize for leaving some folks out, and if you’re one of them, I appreciate your contributions too. :)

We reached our goal in 2018, largely because the goal posts kept moving. We started with a focus on 32-bit, then x64, then we needed to reach codesize parity, then we had to improve debug info quality, and on and on. In some ways, it was the simplest project, because it’s just one marathon, five year burndown of failures.

For me, this journey peaked in late 2020 when I implemented parallel PDB type merging (flag-flip commit). This was the application of ideas about deterministic, parallel programming that I learned in 6.172, finally. There’s not a lot of parallel programming in compilers, but there could be more if we thought in terms of associative operations!

LLVM Foundation Board Member (2022-)#

I think my original reason for joining the Foundation board was out of a desire to move the ball forward on infrastructure. I appreciate the hard work that many talented people have put into enhancing LLVM’s CI, so I say this with love, but if you’ve worked with LLVM, you know our CI is not very good. It is a normal and obvious thing to want to see something better.

I think the main outcome of this was that I got back in touch with Chris Bieneman (beanz), who was now at Microsoft working on HLSL. We were in this post-pandemic era, and Chris Lattner had now moved on from the project multiple times, and it seemed pretty clear that the project lacked coherent leadership. ChrisB cited his stories, mostly focusing on SPIR-V and the graphics space, but everyone can probably tell their own story about how ambiguous the rules and norms are for running the project. So, ChrisB looked around at how other projects do things (Python, Rust, others), and he cobbled together LP-0004, the governance proposal, or a plan for post-BDFL project leadership. Aaron Ballman was concurrently putting a lot of effort into reviving our norms around code ownership, and we formed an informal trifecta working group to push this through and hold the first area team elections. I went to EuroLLVM and held a round table on this topic, Chris gave talks, Tom Stellard helped with Elekto, and things came together for 2025 and we’re just now finishing the first year of the new governance structure. I think it’s still nascent, and my sense is that folks are not yet willing to rock the boat, they are looking for strong consensus before making decisions. However, the core of this whole effort is that we’d probably all be a lot happier if we got clarity sooner rather than waiting interminably on design proposals that seem to be going somewhere, but fail to materialize before some director’s patience wears out, and the upside of knowing is greater than the downside of being told “no”. So, we’ll see where things go in 2026.