Go having its own intermediate representation "solves" the problem but requires go-specific backends/lowering mechanisms. LLVM is arguably a more generic place for backends to live. (though in practice it does serve clang's needs best).

If you design a new processor, you generally take it upon yourself to do the work necessary for folks to use C compilers that target your processors. I'd argue that they're more likely to contribute a backend implementation to LLVM than golang.