gccjit.rs - libgccjit bindings for Rust

This repository contains the basics for some high-level bindings to libgccjit. The raw bindings themselves are in gccjit_sys, within this repository.

Building and running

This project requires you to have libgccjit.so already installed on your machine. You might be able to obtain it from your distro's package manager. I'm on Ubuntu and it didn't look like I could get it with apt-get, so I built it from source. YMMV.

Once you've got libgccjit.so, a simple

cargo build

should suffice. There aren't many unit tests right now, but they can be run using cargo test.

There are four examples right now living in the examples/ directory:

• square_function - A square function, as a simple example for code generation,
• factorial - A factorial function, as a more complicated example involving recursion and conditional jumps. gcc removes all recursion at O3.
• hello_world - An example that invokes a function written in Rust from JIT-compiled code.
• brainfuck - An ahead-of-time compiler for brainfuck. The speed is very impressive given how easy it was to setup with libgccjit. Some benchmarks, my compiler vs a naive interpreter I wrote in Haskell:

sierpinski_triangle, haskell:
   real     0m0.052s
   user     0m0.026s
   sys      0m0.004s
sierpinski_triangle, libgccjit AOT:
   real     0m0.001s
   user     0m0.000s
   sys      0m0.001s
sierpinski_triangle, libgccjit JIT:
   real     0m0.140s
   user     0m0.106s
   sys      0m0.028s
   
mandlebrot_set, haskell:
   real     16m0.317s
   user     15m53.721s
   sys      0m6.291s
mandlebrot_set, libgccjit AOT:
   real     0m1.392s
   user     0m1.374s
   sys      0m0.004s
mandlebrot_set, libgccjit JIT
   real     0m5.498s
   user     0m5.446s
   sys      0m0.041s

The interpreter beats the JIT on the sierpinski triangle benchmark but the JIT blows the interpreter out of the water (170x faster!) on the mandlebrot set benchmark

Error handling

Right now, if you call the APIs incorrectly, gccjit will print angry messages to standard error. It may be worth encoding this into the API. Right now there's no penalty to the APIs returning null (Rust never dereferences the opaque pointers and gccjit doesn't dereference them if they are null), but there's no indication to the user other than the message on standard error that something went wrong.