Sorry for the second reply, but I responded before seeing the stuff below the code block.

For 64 bit X86, Visual C never deviated from the 1 and only calling convention.

1. Firstly, that is a good thing. Much better than the previous world of cdecle, pascal, fastcall et al.
2. Whilst the MSC compiler won't vary the calling convention, it provides the hooks to allow the programmer to do so.

   See the frame attribute of the PROC directive & .ENDPROLOGUE directive

   Scant information, but the possibility.

The question is, are there any compilers daring enough to create a whole DLL/SO which contains exactly 1 function call in C?

Just this morning I read that the LLVM JIT had until recently, a 16MB limitation on its JIT'ed code size, which is now lifted.

Besides which, I don't believe that you need to optimise across function boundaries to get some significant gains (over C compilers) out of the Perl sources.

You pointed out that many of perl's opcodes and functions are huge. Much of the problem is not just that they are huge, but also that they are not linear. The macros that generate them are so heavily nested and so frequently introduce new scopes, and unwieldy asserts, that C compilers pretty much give up trying optimise them because they run out of whatever resources they use when optimising. Too many levels of scope is a known inhibitor of optimisers. That's where inlining can help.

Will LLVM fare any better? Once again, we won't know for sure unless someone tries it.

Another danger, there is a fine line between inlining/loop unrolling, and making your L1 and L2 Caches useless. Blindly inlining away all function calls will cause a multi MB object file per Perl script that won't solve anything.

Once again I ask: are you sure?

If the JIT can determine that this variable -- hash(ref), array(ref) or scalar -- is not tied, has no magic, and never changes its type -- IV or NV to PV or vice versa -- within a particular loop, then it can throw away huge chunks of conditional code. Similarly for utf/non-utf string manipulations; similarly for all the context stuff for non-threaded code on threaded builds.

Note: I say "can", not will. The only way we collectively will know for sure if it will, is to try it.