Note this uses golang.org/x/tools/go/packages and golang.org/x/tools/go/ssa to get to the go SSA AST and then generates some LLVM IR from that. It's not implementing a go parser or the transformation to SSA.
Indeed, I had to take certain liberties in order to cram the talk into 20 minutes! I hope one of the takeaways was that you don't need to implement a parser to get started playing with this sort of thing.
AFAICT parsing is the easy part, admittedly more than 20 minutes but... (Also AFAICT) Go was specifically designed for easy lexing/parsing as part of their core principals.
After you get from text->AST is when all the magic happens. I've been reading up on this off and on for the last year or so and it's less magic than breaking the problem down into (not quite) simple steps that can be studied individually.
It's actually a quite fascinating field to go diving down the rabbit hole -- there's a lot of "lost" ideas from 20-30 years ago that one could take from pseudo-code to a fairly reasonable compilation pipeline without too much trouble. True, it wouldn't win on any benchmark test against something like LLVM with their millions of person hours invested in the optimation phases but it would be reasonable none the less.
What you're seeing is the LLVM IR for the program being printed. As another commenter noted, you can compile the program with make, which just runs `clang` on that IR.
%d is for regular 'int' sized arguments. Most popular platforms have a 32-bit or smaller 'int'. i64 refers to a 64-bit int. For that you would use '%ld' or '%lld' depending on if long or long long was 64-bit. (Or '"%" PRId64' if you really like the inttypes.h syntax.)
somewhat OT but: ended up in the 'go/constant' package's source from there somehow and there saw the comment on "Prevent external implementations" [1] regarding using a non-exported function in the definition of 'constant.Value' interface.
Here is an external implementation of constant.Value: