Currently, OSR takes care of entering Ion from within loops. However, if a function contains no loops, and it's been baseline-compiled, then it will never get Ion compiled because the UseCount fallback stub only compiles on LOOPENTRY ops. Fix the UseCount stub to ion-compile (but not enter) scripts with high use counts.

Note: I realize I'll have to rebase these changes around your fixes to the OSR code. Shouldn't be too bad though. This patch does a couple of things: Changes UseCount_Fallback to store a copy of the script and the pcOffset so that it's not expensive to retrieve. It may be feasible to remove these once we adopt the proper practice of inserting case-specific optimized stubs (I've added TODOs for that) to avoid reaching the fallback stub in the first place. It also changes the DoUseCountFallback function to potentially invoke an ion compilation even if the PC is not at a LOOPENTRY. The expectation is that the next time the function is entered, we'll enter the ion code. This cuts access-binary-trees runtime to a third of what it was before with baseline+Ion.

Comment on attachment 710430 [details] [diff] [review] Patch Review of attachment 710430 [details] [diff] [review]: ----------------------------------------------------------------- Nice, r=me with the comment below addressed. ::: js/src/ion/BaselineIC.h @@ +829,5 @@ > class ICUseCount_Fallback : public ICFallbackStub > { > friend class ICStubSpace; > + HeapPtrScript script_; > + uint32_t pcOffset_; With the OSR patch I just pushed, we don't have to store the script here but can get it from the BaselineFrame * pointer passed in. We can get the pcOffset from icEntry()->pcOffset() I think. Especially b2g has very strict memory requirements, so every word we can save in our IC stubs is great.