LRecover goals is to provide a linear way to iterate over the list of dependencies of recover instructions (MResumePoint / MInstructions). FlattenedMResumePointIter is doing this operation 3 times and save the recorded sequence into a vector of MResumePoint. We should cache the result of the vector and keep the result of the flatten vector instead of computing it 3 times.

This patch is still using LRecover, I will rename the class to LRecoverInfo locally, as mentioned on Bug 989344.

Comment on attachment 8398977 [details] [diff] [review] Move FlattenedMResumePointIter into LRecover Review of attachment 8398977 [details] [diff] [review]: ----------------------------------------------------------------- Nice cleanup, r=me with comments addressed. ::: js/src/jit/LIR.cpp @@ +144,5 @@ > + MResumePoint *it = mir_; > + > + // Sort operations in the order in which we need to restore the stack. This > + // implies that outer frames as well as operations needed to recover the > + // inner frame content are located before. The top-level resume point should Nit: "This implies that outer frames, as well as operations needed to recover the current frame, are located before the current frame. The inner-most resume point should be the last element in the list." ::: js/src/jit/LIR.h @@ +878,5 @@ > > class LRecover : public TempObject > { > + public: > + typedef Vector<MResumePoint *, 0, IonAllocPolicy> Instructions; s/0/2, some inline storage to avoid the alloc-more-memory dance in the common case. There will always be at least 1 element in the vector. @@ +881,5 @@ > + public: > + typedef Vector<MResumePoint *, 0, IonAllocPolicy> Instructions; > + > + private: > + // List of instructions needed to recover the stack frames. Add: "Outer frames are stored before inner frames." @@ +889,1 @@ > MResumePoint *mir_; Do we still need to store this one separately if we also store it in the Vector?

(In reply to Jan de Mooij [:jandem] from comment #2) > @@ +889,1 @@ > > MResumePoint *mir_; > > Do we still need to store this one separately if we also store it in the > Vector? No, I will assert about it in the init function and modify the mir accessor to pick the last element of the vector.

Backed out for B2G bustage in the push. https://hg.mozilla.org/integration/mozilla-inbound/rev/c4d1adee6057 https://tbpl.mozilla.org/php/getParsedLog.php?id=37290188&tree=Mozilla-Inbound