Adding branching (MPC -> LLVM for the Neil Language #4)

This is part of a series, the first three parts of the series can be found at: Hooking up MPC & LLVM Cleaning up the parser Adding type identifiers In this post, we’ll cover how to add branching support to our little toy language I’m calling Neil - Not Exactly an Intermediate Language. To keep things simple, I’ve decided to add branching of the form: With the following caveats: we will not support else branches we will only support <.

Introducing YARI-V - an experiment on SPIR-V compression

SPIR-V is a simple binary intermediate language used for graphics shaders and compute kernels. Wearing my work hat (I work at Codeplay Software Ltd.) I have been contributing to the SPIR-V specification since 2014 as one of the authors. SPIR-V’s primary goals are (as according to me): Have a regular binary structure. Be easily extendable. Be easy to validate for correctness. Be easy to produce from compiler toolchains. Be easy to consume in tools and drivers.

spirv-stats update - exposing more information

In a previous post I introduced a little command line tool spirv-stats I’ve been working on. Since doing the initial version, I’ve extended the information the tool will give you based on some queries I had on the SPIR-V binaries we were using - in the GitHub pull request here. For the most commonly used opcodes, I’ve tried to break them down to understand a little more about the shape of the opcodes.

spirv-stats - a tool to output statistics of your SPIR-V shader modules

I’ve just released a small one C++ file tool called spirv-stats. It will take one or more SPIR-V input files, and calculate the composition of the SPIR-V shader modules like so: It firstly outputs the total number of hits in the SPIR-V shader module(s) - this is the total number of opcodes found within the module(s). Then it outputs the total byte size of the module(s), followed by a sorted breakdown of the module(s), with the most hit opcodes coming first.

Adding type identifiers (MPC -> LLVM for the Neil Language #3)

In my previous post cleaning up the parser, I had rationalised the parser for my custom language I’m calling Neil - Not Exactly an Intermediate Language. The next step in making my language more useful and expression is to add the ability to arbitrarily create variables within a function, store an initial value to the variable, and then be able to update the variable. Previously, our language could handle: Whereas now we want it to be able to handle: