Prepack: Potential optimizations of arbitrary functions

[skyne98]

Hello there!
I was playing with different ways of using prepack and stumbled upon an interesting topic, that made me rise a question.
Can prepack somehow (potentially) optimize such obviously optimizable functions?

(function(){
  function foo(x: number) {
    return x + "a" + "b";
  }

  global.foo = foo;
})();

I can assume that there are two potential problems with this:

1. Prepack is just a complex compile-time evaluator, which is not supposed to handle situations like this.
2. We shall not optimize functions because of potential use of ".toString()"?

Looking forward to your opinions!

[hermanventer]

Prepack has the potential to be a general purpose whole program optimizer, provided that certain language constructs, such as eval, are avoided. In this current state, this is not possible, but it falls within the scope of our ambition for the tool.

Point 2 is relevant as an illustration why the term "whole program" is the key to unlocking the potential of Prepack. I.e. as long as we know for sure which function will be invoked to convert numbers to strings, we can happily optimize the example function. Of course, knowing something like that _for sure_, is no mean feat.

[skyne98]

Yeah, you are doing a great job, guys! I am sure that in some time it will become a great and universal tool.
As for now, I was wondering wether the combination of both Prepack and Closure Compiler can bring desired results?

[hermanventer]

Running Closure over the output of Prepack should be possible and hopefully will give you better results than running Closure only.

[skyne98]

Yeah, thanks :) Another question. What if there was some hypothetical programming language, that had compiler-checked pure functions? Would Prepack and Closure together benefit from a language having such a feature? (except memoization, for sure)

[hermanventer]

Right now, probably not. In the long run, Prepack may be able to use pure annotations as a way to speed up the analysis.

[skyne98]

Yeah, pure annotations is a great idea, I think. However, I am curious about what real optimizations you can apply, having this function purity data? Constant folding is obvious, what else?

[hermanventer]

If a function is pure, it will not change the global state when invoked. Before we can optimize call backs, we need to generalize the heap that resulted from the global code to incorporate any modifications that can result from call backs. This involves a fixed point loop and joining the effects of all functions that may effect the heap.

Knowing up front that a function is pure, means that it does not have to be analyzed as part of the fixed point loop, which makes that computation a bit cheaper.

A further win would be when the function is called. Normally we'd have to inline the function body in order to discover any effects it may have on the calling and global state. This has to be repeated for every call site along every possible execution path, which leads to exponential blow-up in analysis time. Knowing that function is pure means that we don't have to do this.

Of course, it is possible to make Prepack discover pure functions all by itself, so having another tool tell it a function is pure is not necessarily a game changer. Unless, of course, the body of the function is not going to be available to Prepack, in which case such an annotation will make a world of difference.