I understand that strategy, and it's probably easier to start to see results than most other approaches, but keep in mind a few drawbacks:

• You have to compile every part of the system to LLVM bitcode, including the Perl core, any modules you use, and every XS component. This is cacheable, but you still have to do it.
• Before running a program, you have to link all of the bitcode together into a single image. This image will be large.
• Before running a program, you really want to run as many of LLVM's optimization stages as possible. This takes time and memory.
• You may be able to emit native code which represents only that program and execute that. Essentially you're replicating what PAR does, with all of the caveats about program analysis and requirement discoverability.

I expect the resulting binaries to be huge. I expect the link and optimization steps to take a long time. I expect you'll have to keep the Perl 5 interpreter around anyway because there are things you just can't do without either rewriting the language (to get around the BEGIN/import symbol declaration dance, for example. I don't know if you have to include any LLVM runtime components.

I can imagine that you can optimize some programs with this approach, but I don't know that the intrinsic overhead in the Perl 5 VM you get is more than 10%. Maybe link-time optimization can cut out another 10%. Part of that is the inherent flexibility of Perl 5's design, and part of that is that LLVM is at heart a really good compiler for languages that act like C++.