Thanks for the link Reini.

I can see that I am duplicating some of Yuval's efforts, but I think it will be worth it.

Beyond simply using llvm as an alternate C compiler -- though if doing so recovered (some of) the 15% to 30% loss of performance that has come about since perl5.6.1 with the additions of threading and Unicode support, that alone would be worth something -- I also want to explore what benefits (or not) are derived from the passes of the individual optimisers in llvm, on a the various groups of the perl core.

For now, my chosen task of having llvm-built binaries (perl.exe/perl5x.dll) that inter-operate with an otherwise standard distribution and modules -- including XS modules -- built using the normal compiler for the platform is (cautiously) going well. Most of the problems I've encountered so far result from my choosing to use MSVC rather than a gcc-compatible compiler to build the distribution I am inter-operating with. Simple reasoning: if I can make LLVM inter-operate with MSVC, gcc/mingw should be a doddle; but more importantly, inter-operation on other more obscure platforms should also be possible.

One of the bits of using LLVM that has gone completely unmentioned in all of the discussion I've seen so far, is the benefits of using its (frankly amazing) analysis & tracing tools. I've learnt more about the structure (and cruft) of the perl internals in the last 100 hours than in the previous 5 years.