This looks awesome!

What are the important limitations? I'm guessing it's not going to help detect that if only X were true, the register allocator would have avoided spilling any registers. I suppose that doesn't fit into "high-level optimization decisions". But what sorts of things could have a large impact on performance that this cannot handle?

It looks like right now the TrackedStrategy is going to be very unstable. What policy is there for updating it (eg append only)? Do we need a new subtrahend to increment? Or is there a mapping layer to mitigate the API instability? How much does it matter?

On 02/05/2015 04:20 PM, Shu-yu Guo wrote:
Greetings, fellow subtrahend incrementers!

I recently landed bug 1030389 to track the high-level optimizations
decisions
(i.e., deciding what MIR is emitted) made by IonBuilder. This information
will feed into the profiler and is attached to sampled JIT frames.

Currently, getprop, setprop, getelem, setelem, and calls are tracked. I
should
like to introduce the API here so that upcoming patches of new optimizations
like the SIMD.js optimizations are tracked from the beginning.

High-level description
----------------------

Optimizations are tracked by bytecode location. The API allows each bytecode
location to track two things: optimization attempts, and type information.

Each optimization attempt is is a pair of (strategy, outcome). These are
implemented by the enums TrackedStrategy and TrackedOutcome in
js/public/TrackedOptimizationInfo.h. The strategy describes the optimization
Ion is attempting to emit (e.g., a definite slot load), and the outcome
describes a specific reason for its success or failure (e.g., failed due to
no type info).

Each bytecode location can accumulate a list of attempts. This list is
terminated by the first successful attempt. The slow path is not encoded as
its own attempt pair and is inferred from a list of attempts whose outcomes
are all failures. That is, if only the slow path succeeded, the attempts
list
will all failed attempts.

Each tracked type is a triple of (site, MIR type, type set). The site is
described by the enum TrackedTypeSite.

API
---

Add the specific attempts, outcomes, and type sites you need, if not already
present, to the enums in js/public/TrackedOptimizationInfo.h.

To start tracking optimizations for a bytecode location,
call |startTrackingOptimizations()|.

Usually, types are tracked in the beginning by
calling |trackTypeInfo(TrackedTypeSite, MIRType, TypeSet *)|.

Before attempting to apply a strategy (e.g., before the call to
getPropTryConstant), call |trackOptimizationAttempt(TrackedStrategy)|. By
default, the outcome of the attempt is "generic failure". To refine the
outcome, call |trackOptimizationOutcome(TrackedOutcome)|.

There is the convenience function |trackOptimizationSuccess()| to track
successes. Be sure to call this on successfully applying an optimization! In
methods like IonBuilder::jsop_getprop where a series of strategies are tried
one after another, each |*emitted = true| assignment should be accompanied
by
a call to |trackOptimizationSuccess()|.

All tracking methods are infallible. OOM during tracking disables
optimization
tracking instead.

That's it! Instrumentation bugs also make great first bugs, and I would be
happy to mentor.


_______________________________________________
dev-tech-js-engine-internals mailing list
dev-tech-js-engine-internals@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-js-engine-internals

Reply via email to