Scalar replacement of aggregates means replacing an object allocated on the heap (for example, Point p = new Point) by local variables corresponding to its fields (double x, double y)

Removing the object allocation saves time and puts less pressure on the GC. Replacing the instance variables with local variables may also allow the compiler to optimize some things that it would not have attempted to optimize before. For example, storing them on machine registers.

Right, and in a language where you are predominantly using strings, arrays, maps, unless you can remove and optimise through these data structures you spend your whole time allocating them, collecting them, doing lookup in them and you won't have any opportunity to apply other optimisations. You need to be able to understand these data structures at the level of an IR - DynASM or LLVM aren't going to remove a call to a lookup routine for you.

I understand that a JIT engine cant do this, due to speed.

But would be surprised that a LLVM compiler with a custom-designed heuristic for specific optimizations cant manage this.

These problems may be polynomial etc etc, but MOST of the code generated should follow common patterns

I will have to give this some thought.

Thanks for the reply (also GP)

> I understand that a JIT engine cant do this, due to speed.

Most serious JIT engines do! For example V8, LuaJIT, Graal, C2.

> But would be surprised that a LLVM compiler with a custom-designed heuristic for specific optimizations cant manage this.

Rubinius for example tried writing custom optimisations like you're describing and didn't get very far. LLVM is not designed for these kind of optimisations - it understands memory reads and writes, not high-level semantic information about arrays and objects.

In practice, it just doesn't seem to work.

As I say I think it's a bare minimum for making a dynamic language genuinely fast. I gave a lecture about this https://www.youtube.com/watch?v=b1NTaVQPt1E.