Author of LuaJIT explains why compilers can't beat hand-coded assembly

Re:Author of LuaJIT explains why compilers can't beat hand-c... by fmap on Friday May 27, 2011 @05:31AM (#2590926)

I don't really know Microsoft's C compiler well enough to answer why your specific example fails so spectacularly, but I can make a guess: You are using inline assembly containing a computed jump instruction. In this situation the compiler no longer has a complete view of the control flow graph of your function, and it is likely that all optimizations which need a control flow graph will be disabled. Common subexpression elimination needs a CFG since it determines if two computations are the same for all paths in the program.

Now I'm reasonably certain that the C standard does not allow inline assembly like this. However, given the decades of legacy software that Microsoft has to contend with I would not be too surprised if this was part of the reason.

By the way, GCC's computed gotos are not actually much better. In this case you get a control flow graph where you cannot split all critical edges. There is a workaround for this, but it's probably easier to just disable all optimizations that depend on it.

[ Parent | on HN ]

Re:Author of LuaJIT explains why compilers can't beat hand-c... by chrisb on Friday May 27, 2011 @10:15AM (#2591503)

I've tested that inline assembler performing the computed goto in a smaller test function, and optimisation is performed.

And almost all of the C code that I would like to be optimised is in short fairly self-contained statements that use their own local variables, so I would expect Again, I've tested this in a smaller function and good optimisation is done.

Therefore I am coming to the conclusion that the problem may just be the length of the function.

I don't have time to do it now, but next week I'll experiment with function length, although as I stated ealier - I'm fairly sure that a threaded interpreter has to be all implemented within a single function.

[ Parent | on HN ]