Neil Henning

In this post, we’ll use floating-point scalar evolution (fpscev) to simplify instructions based on any range data we’ve managed to deduce.

As a follow-up to my post An Experimental Floating-Point Scalar Evolution, I’ve started looking into using my previous analysis to actually change the LLVM IR for the better.

The TL;DR - after a conversation at EuroLLVM with Steve Canon about how LLVM is missing scalar evolution analysis for floating-point, I’ve spent some spare time hacking on a new LLVM analysis pass - fpscev (Floating-Point SCalar EVolution) - available here

For those that don’t know - the favourite single-header C/C++ library that I’ve ever created is my unit test helper - utest.h.

I’ve long been frustrated with wordpress as the way I post content on my blog: It is bloated and slow to load pages.

I’ve been continuing my foray into Rust, and one thing I’ve been interested in is global allocators - Rust’s builtin support for switching the allocator used by an application.

2018 has been a very busy year for me personally, and I thought for the sake of my own memory of the events I’d do a review of the things I’ve managed to achieve this year.

So I’ve been playing around with Rust in my spare time for a few months now, and have been doing a lot of stuff that bridges C/C++ and Rust content.

After 11 years since my first internship, and 9 years full time, I’m leaving Codeplay to join AMD.

I’ve been meaning to try out Intel’s VTune now that it has a permanent trial mode (you can renew the 30-day trial license every 30-days without paying!)

After my previous post on how to read & write LLVM bitcode, I thought I’d follow it up with a post on actually modifying LLVM bitcode files after you’ve read them.

I’ve read multiple posts on social media now complaining about how scary LLVM is to get to grips with.

I’ve had a lot of people using my unicode library utf8.h since its release - thanks to all who’ve found the library useful and provided feedback!

I’ve long been after a cross-platform way to launch processes and interact with them for use from C & C++.

One component of Codeplay’s ComputeAorta that I manage is our high precision maths library Abacus.

LLVM comes with a really useful set of options LLVM_USE_CRT_ which allows you to specify a different C RunTime (CRT) when compiling with Visual Studio.

I gave a talk on Friday 13th of October 2017 at the Khronos Munich Chapter titled ‘OpenCL to Vulkan: A Porting Guide’.

Previously I had begun a series of blog posts detailing how to port applications from OpenCL -> Vulkan.

Vulkan is the newest kid on the block when it comes to cross-platform, widely supported, GPGPU compute.

Vulkan is the newest kid on the block when it comes to cross-platform, widely supported, GPGPU compute.

Vulkan is the newest kid on the block when it comes to cross-platform, widely supported, GPGPU compute.

I’ve added JSON 5 support to my json.h library.

This is part of a series, the first four parts of the series can be found at: Hooking up MPC & LLVM Cleaning up the parser Adding type identifiers Adding branching In this post, we’ll cover how to add loops to our little toy language I’m calling Neil - Not

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 Ex…

SPIR-V is a simple binary intermediate language used for graphics shaders and compute kernels.

In a previous post I introduced a little command line tool spirv-stats I’ve been working on.

I’ve just released a small one C++ file tool called spirv-stats.

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.

I was recently made aware of the awesome JSON parser/writer benchmark suite nativejson-benchmark (thanks to the awesome @chadaustin).

In my previous post Hooking up MPC & LLVM I had started hooking up MPC to LLVM, to start developing a custom language I’m calling Neil - Not Exactly an Intermediate Language.

I’ve been tinkering around with mpc and llvm recently - just to satisfy a few simple questions: How easy is it to use mpc?

With all the buzz surrounding Vulkan and its ability to make graphics more shiny/pretty/fast, there is one key thing seems to have been lost in the ether of information - Vulkan isn’t just a graphics API, it supports compute too!

While at GDC I got a feature request from the awesome folks over at Blastbay Studios requesting that they could feed an allocator to json.h, my JSON parsing library.

Most of my company projects have a requirement that we run clang-format on all commits to keep a consistent style.

In a previous post (Partial) Simplified JSON support in json.h I covered the partially added simplified JSON support I had added to json.h.

So as you may (or may not) already know - I’ve written two tiny C libraries - utf8.h and json.h.

With the help of the rather awesome @ocornut - I’ve managed to get a variant of simplified JSON support into json.h!

So previously I tested my json.h library’s performance against other JSON libraries in the wild (json.h performance (vs other C/C++ JSON parsers).

One of the first questions I had when I open sourced my json.h library was how fast it can parse compared to other commonly used JSON libraries around.

Back in May, the rather awesome imgui creator @ocornut asked the following; And it got me thinking - why isn’t there a simple JSON reader/writer lib in the same vein as the stb_* libraries that performs a single call to malloc to encode the state?

Since my last post introducing utf8.h I’ve been frantically working on fleshing out the core utf8* functions to match the str* ones, and also listening to developer feedback!

I’ve been tinkering around with a new one header library (having been inspired by the awesome stb libraries that @nothings created), a utf8 string library https://github.com/sheredom/utf8.h.

I’m quite particular about how I word the variables that are exposed via my APIs.

Just about everyone has used the size_t type - and everybody and their grandmothers know what the type means of course!

So I previously installed Jenkins on my Raspberry Pi 2, and ran my first job through Jenkins.

So in my last post Installing Jenkins on Raspberry Pi 2 I took us through the steps it took me to get a Jenkins server running on my Raspberry Pi 2 - but I didn’t actually run any jobs on the Raspberry Pi 2!

So I’ve always wanted to roll my own home continuous integration (CI) server - I use Jenkins as my main CI at work (having used Atlassian’s Bamboo and the hideousness that is buildbot in the past), so I thought I may as well start there.

I’ve uploaded my slides with speaker notes for the Khronos/EuroLLVM talk I gave this week.

After reading “SIMD at Insomniac Games – How we do the shuffle” I realised I hadn’t done anything with my new Raspberry Pi 2 yet.