Here is an -O1 Visual C Perl 5.17 disassembly of pp_add. I chose to compare pp_add to C/Asm since in C an add is typically 1 asm op. now for preprocessor output. until this whole function is reduced to a single fadd, lea, or add machine opcode, your performance will never be anywhere near C's speed. Simply using B::CC/B::C with LLVM wont work. Removing and optimizing out the Perl from perl is required. Once magic/tied and eval are added, removing Perl from Perl becomes very hard. You can't eliminate any variable access expressions, since they are tied. If I write

#psuedo code probably
sub NewUser{
$Users{$_[0]}{'Locations'} = $magicHash{'NewRecord'}->AddClientLocatio
+ns($magicHash{'NewRecord'}->AddLocation($magicHash{'NewRecord'}));
}
[download]

Can you eliminate dereferencing %magicHash thrice?

On sub entry do you scan @_ for magic? What if you make a call to another sub and it decided to tie your lexical now knows as $_[0]? What about eval (I presume any sub with an eval simply stay as legacy Perl opcodes, unoptimized to "C speed")?

Rather than use LLVM, why not write a Perl to Javascript compiler and let the platitudes of Javascript engines duke it out? JS engines nowadays receive massive amounts of pressure and money from the public and from project managers to quickly handle larger and more bloated AJAX JS libraries every day. Some of the modern JS engines claim to do what LLVM already does with JIT to machine code.

edit: fixed broken tags