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. Fast-Math Flags LLVM has a way of encoding the fast-math flags on various floating-point operations. These flags let the compiler assume something about the operation, which generally allows more performance. Of these flags, there are two that can use my previous floating-point scalar evolution (fpscev) analysis to propagate through other instructions - no-NaNs and no-inifinites.
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 at github. The pass will analyze floating-point operations in a function and work out if there are any constraints on the range of these values, information which can be used to better optimize code.
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. The main features are: Single header (duh). Works with C and C++. Allows a single executable to be created with both C and C++ tests linked in. Blindingly fast to compile and run. After reading this post on another attempt at a googletest replacement jctest, and all the awesome analysis that Matthias included comparing the compile and runtime performance of jctest as compared to googletest, it suddenly hit me that I haven’t actually provided my performance analysis in any blog to show how good utest.
I’ve long been frustrated with wordpress as the way I post content on my blog: It is bloated and slow to load pages. Requires an SQL server for content which is mostly static. I find the editor unintuitive. Code samples never quite displayed correctly. I’ve been looking at Hugo for a while now as I love the idea of static site generator, but everytime in the past I tried to switch to it in the past but I was frustrated by the export to hugo plugin for wordpress being broken.
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. One thing I’ve been wanting to try for a while is to see if a bump allocator used in conjunction with a short running application could result in performance gains. I couldn’t find while perusing crates.io any crate that added a global allocator that just bumps, so I’ve written my own - bump_alloc.