After 11 years since my first internship, and 9 years full time, I’m leaving Codeplay to join AMD. A Brief History of Codeplay and I I was a nineteen year old ned when I started my first internship at Codeplay, and was given the code-monkey job of hand optimizing shaders for an OpenGL ES 2.0 shader compiler, so that Codeplay’s compiler engineers could prove the capability of the compiler. Slated to take 10 weeks, I finished the task in 2 weeks and to stave off boredom in the remaining 8 weeks I ended up proving 100% code coverage of the compiler and writing a test generator to break it.
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!), as I’ve long heard people rave about it as a profiling aid. I decided to pick one of my open source C libraries and see what performance problems I could find in the code, and I choose my JSON parser json.h. I’ve long known that the recursive approach I used in the parser will limit the performance I can get out of the code as compared to some of my competitors, but I support a metric-ton of extensional functionality (simplified JSON and JSON5 to name two major extensions that my users love).
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. LLVM comes with extensive built-in optimization passes, but also plenty of scope to do your own optimizations too. First off, remember that that when we parse an LLVM bitcode file, we get an LLVM module. So what exactly is an LLVM module?
I’ve read multiple posts on social media now complaining about how scary LLVM is to get to grips with. It doesn’t help that the repository is ginormous, there are frequently hundreds of commits a day, the mailing list is nearly impossible to keep track of, and the resulting executables are topping 40Mb now… Those tidbits aside - LLVM is super easy to work with once you get to grips with the beast that it is.
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! One of the things that I’d scrimped on previously was my support for case-insensitive comparisons for letters beyond those in ASCII. I knew little about this, but when a user requested that my library also supported accented latin characters, and later greek symbols, I jumped to the occassion to add support.