Rust basically works wherever llvm does, and nowhere else. So it works fine on most risc-v and Power targets.
Embedded targets need platform specific standard library support of course but as far as hosted implementations go that is the main factor.
As well as on GNU/linux: you always need platform specific library support.
For example, if you write a sandbox, you're dealing not only with the
libc {glibc, MUSLc, dietc, ... } but with parts of the code that are highly architecture-dependent. That is, you have to manipulate registers and the stack in assembly, and these parts are "architecture-specific."
I know this because I had to fix ptrace and write a sandbox, which has strong kernel dependencies. With this kind of thing, I had to write a lot of custom code.
The secondo problem is that llvm is not a piece of "simple software", and it's unstable (they say "experimental") on HPPA and MIPS, probably due to lack of interest as HPPA and MIPS are not "mainstream architectures".
So the point is that it requires much more effort than supporting e.g. the C language on gcc.
llvm requires much more effort from this point of view, and that's why we have gcc (language={c, c++, fortran}) working on HPPA and MIPS, while we only have an experimental llvm
I think I'm the only one in the world to have ported and used ADA on HPPA-v1 (32bit userland), gcc (language={c, c++, fortran, ada}), and this shows how little interest there is in HPPA, and consequently how few people care about solving all those small and large problems involved in porting a compiler, or a framework like llvm.
It took me four bloody years to have it working!