search for: monomorphisation

...imizations that I need to get to work are: * Tail call elimination. * Constant evaluation. To implement this, the JIT phase would have to evaluate the constant and somehow store it so that future runs don't need to reevaluate it. * Dead code elimination, enabled by constant evaluation. * Monomorphisation, i.e. constant evaluation may establish that some data structures aren't polymorphic, so it would be worth generating code that keeps integers in registers instead of generating boxed representations on the heap. Again, constant evaluation can enable this optimization. I'll be...

On Wed, Nov 11, 2015 at 07:14:28PM -0800, Sean Silva via llvm-dev wrote: > Can you show a real benchmark that users have tried to write where the call > overhead of actually using an external function call is measurable? This is the wrong question. The correct question is: What useful benchmark cannot trivally factor out the overhead of the external function call. Yes, if you do

...Dead code elimination, enabled by constant evaluation. LLVM has both constant propagation and dead code elimination, but if your language has a high-level functional concept of "constant" here (or you're referring to memoization), your runtime may need to help LLVM out. > * Monomorphisation, i.e. constant evaluation may establish that some > data structures aren't polymorphic, so it would be worth generating > code that keeps integers in registers instead of generating boxed > representations on the heap. Again, constant evaluation can enable > this optimizatio...

The memory consumed by the code compiled is huge in server applications. And it is not shared by different virtual machine instances. By contrast, shared libraries are memory mapped, therefore they are shared between different instances of the executables using them. It is posible to throw away code after using it, but then compilation cost would be repeated. And dynamic compilation prevents

Ramón García wrote: > I would prefer to see actual code to make safe schedules. With code I can see > what changes one must make. I can also show in detail these changes, > which would give security to the LLVM project that the proposal is > viable. By contrast, > without code, neither me nor LLVM project can ensure that the project will > be successfully performed behind

Hi Richard, You don't appear to have addressed my suggestion to not require a perfect external world, instead to measure the overhead of an imperfect world (by using an empty benchmark) and subtracting that from the measured benchmark score. Besides which, absolute benchmark results are more than often totally useless - the really important part of benchmarking is relative differences.