The paradoxical reason why pragmas don't work well is that the machine is better than the human.

http://lua-users.org/lists/lua-l/2011-01/msg00978.html

"Also, it's not a good idea to second-guess the region selection heuristics. I tried this many times ('This can't be the best path!') and failed miserably. The selected traces are sometimes very strange, but so far they turned out to be near optimal. It's quite embarrasing if your own creation turns out to make smarter decisions than yourself. ;-)"

What you'll ultimately end up doing is spending more time fiddling with pragmas and code layout trying to control what machine code the compiler produces than you save by not writing the assembler directly yourself.

It has to be said, though, that we really are talking about a critical loop here. This is no real justification for using assembler instead of a compiler outside of extremely hot (or extremely odd, e.g. dynamic invocation, coroutine stack switching etc.) pieces of code. An interpreter loop is the ultimate hot loop; all code goes through it.

Coroutine stack switching doesn't need assembler in many C implementations: http://fanf.livejournal.com/105413.html?nc=6

Sure, if you presume the existence of setjmp and longjmp. I'm more normally in the position of writing those routines, not using them.

I wonder how close you'd get to that by running the interpreter with gcc's or llvm's profiling on, and then recompiling with profile-guided optimization. If it's just a matter of compilers having heuristics tuned towards the wrong kind of workload, PGO ought to re-tune them appropriately, if enough of the heuristics in question actually look at the profiling data.

I was thinking this too - you would think that profile guided optimisation ought to be able to identify the slow paths.

Either way, I think the field would benefit if tools like that made writing fast JIT VM easier.