1331882 - Enable tracking jsop_array/jsop_object optimizations when inlined as native.

Status: RESOLVED INCOMPLETE

(Core :: JavaScript Engine: JIT, defect, P3)

Description

[Hannes Verschore [:h4writer]]

Disabled in bug 1330363 since this isn't possible with the current code. Shu explains:
> I see, this is unfortunate. There's no way to distinguish restarting the optimization of a bytecode vs what's going on with the inlining of new Array here: that the inlining of a call becomes equivalent to another bytecode that has its own set of optimization criteria.
> 
> The right thing to do here would be to keep both sets of optimization info somehow. The way optimization info is kept for inlining decisions right now is very naive. We assume for N call targets, there are exactly N attempts (see the amendOptimizationAttempt call in IonBuilder::inlineCalls), where the i-th index into the attempts_ vector is for the i-th target. There's no space for the NewArray sub-attempts to go. For tracking inline sites, we could do the following:
> 
> 1. Keep a map of the call target index to the attempts_ index, and just store the sub-attempts in between targets. For example, suppose I have 2 call targets. Target index 0 is a NewArray and has 2 sub-attempts in for jsop_newarray. The optimization info would look like:
> 
> attempts_[0] is (Call_Inline, Inlined)
> attempts_[1] is (NewArray_Foo, ...)
> attempts_[2] is (NewArray_Bar, ...)
> attempts_[3] is (Call_Inline, ...)
> 
> targetIndexToAttemptIndex[0] is 0
> targetIndexToAttemptIndex[1] is 3
> 
> 2. startTrackingOptimizations would need to know when it's being called from inlining code and not clear out the optimizations.

We should fix the infrastructure to allow this.

Comment 1

[André Bargull [:anba]]

IonBuilder builder bug, therefore resolving as INCOMPLETE.