Please review Range Analysis (JBS-8006069)

[Attila Szegedi]

Sorry for chiming in late for this, but:

Minor things:
  - you could have a pre-created constant Range object for Range.createRange(1)
  - assignedInLoop could have enterDefault() that returns assignmentsInLoop.isEmpty() to short circuit when an assignment is found. Actually, maybe don't even need a "HashSet assignmentInLoop" there, just a boolean[1] or an AtomicBoolean for "assignmentFound".

What looks like an actual bug:
  - the visitor of assignedInLoop should only add getInit() and getModify() of a ForNode to skip set when forNode == loopNode. Otherwise an assignment in a nested loop initializer will slip past.

Attila.

On May 20, 2013, at 2:28 PM, Marcus Lagergren <marcus.lagergren at oracle.com> wrote:

> Webrev @: http://cr.openjdk.java.net/~lagergren/8006069/
> 
> Range analysis, trying to narrow known compile time types to narrower ones. (typically doubles to ints or longs). 
> 
> Range analysis is disabled by default, enabled with flag --range-analysis. Aiming to make it default after testing.  I've added unit tests to provide sanity check (same results) and code coverage that runs with the flag enabled.
> 
> I've also done some changes to RecompilableScriptFunctionData to specialize more aggressively and based on runtime types if those are more specific than types known at compile time (adding guards to verify that the assumption holds). Still disabled by default (--specialize-calls is the flag). 25% performance increase on octane.crypto running with it enabled.
> 
> These changes provide an infrastructure for trickle-through of all known compile type information, but this is not enough for performance. We need to do even more aggressive things at runtime. 
> 
> /M
> 
> 
>