LLVM was always intended to be a compiler IR rather than a "JIT for C", and the "virtual machine" in the name was named as much to refer to the idea that it's a more direct model of an instantiation of the C abstract machine as any actual ability to perform dynamic optimization.
The big push LLVM made early on was on being able to do ahead-of-time, runtime, and idle-time optimization; the latter of which is mostly reflected in profile-guided optimization. The poor quality of its dynamic optimization [1] and the general reluctance to use profile-guided optimization means that LLVM ended up focusing hard on optimizing ahead-of-time like traditional C compilers. The fact that people got too easily confused about what LLVM actually did caused Lattner to de-acronymize it officially several years ago.
[1] A more difficult problem for C and C++ is that actually collecting enough of the code in a single IR representation is surprisingly hard, as build systems are completely and totally inane, and that's before you start trying to figure out how to glue in things like assembly files or glibc.
The big push LLVM made early on was on being able to do ahead-of-time, runtime, and idle-time optimization; the latter of which is mostly reflected in profile-guided optimization. The poor quality of its dynamic optimization [1] and the general reluctance to use profile-guided optimization means that LLVM ended up focusing hard on optimizing ahead-of-time like traditional C compilers. The fact that people got too easily confused about what LLVM actually did caused Lattner to de-acronymize it officially several years ago.
[1] A more difficult problem for C and C++ is that actually collecting enough of the code in a single IR representation is surprisingly hard, as build systems are completely and totally inane, and that's before you start trying to figure out how to glue in things like assembly files or glibc.