Julia has an interesting split here, it does the lowering into SSA from in pure Julia and then has a codegen steps that translates the SSA from into LLVM IR, but for that second step we do use the C++ API. We have very robust bindings to the C-API, but it forever feels just a bit incomplete and less cared for. The C-API is very stable, whereas the C++ API does change quite a bit.
Having recently had the pleasure of having to debug JIT-compiled code with an ABI mismatch, I can't overstate how useful `rr` (https://github.com/mozilla/rr) can be to debug assembly. The ability to `rsi` e.g. reverse step instruction is very powerful.
One tool that I started exploring is https://pernos.co/, the ability to do dataflow analysis is super cool. Let's you easily answer the question "How did this value get into this register".
I don't disagree with the sentiment, but using the moon as an example is a bit far-fetched, as well as the metric being time. I thinkl it would be fair to say: Using the same amount of resources, how hard is it to reach a given point?
There is always someone who will fly a helicopter into the remote outback...
> is very possible to be trapped by weather for days, weeks, even months. That is more remote than any island.
Except those islands that you can't reach due to weather for days, weeks or, even months...
It all depends on which optimizations you enable and LLVM is very flexible, albeit sometimes you still spend 20% of your time in ISel (Instruction Selection)...
It's being worked on. I am rather excited for the upcoming work that makes the parser replaceable and allows us to actually give good syntax errors! There is some discussion about making error printing more configurable so that one can skip stack-frames that are unlikely to be the cause (albeit that's a double-edged sword).
I recently spend two weeks on and off hunting down a bug on a platform that didn't support `rr`. I am fairly confident to say that if I had `rr` available it would have taken me a couple of hours at most.
Being able to run backwards from the point of failure and understand where a value is coming from is very powerful.
Having this available in Julia directly is great, and will make it much easier to get bug-reports from users.
We are indeed interested in targeting AMD GPUs. There is a prototype backend available at https://github.com/JuliaGPU/AMDGPUnative.jl and we are closely following the status of SPIR-V and Intel GPUs in LLVM.
The focus on CUDA comes from the fact that most HPC systems for scientific computing are using Nvidia GPUs. That is finally slowly changing.