This is starting to be essential because of the need to optimize create_arguments, create_activation, among others. The point is that if these opcodes appear on paths that dominate the exit, then we should hoist them and have them execute unconditionally.
Created attachment 139599 [details] the patch
Comment on attachment 139599 [details] the patch View in context: https://bugs.webkit.org/attachment.cgi?id=139599&action=review r=me, but i'd prefer it if you made the m_array member of FastBitVector an OwnArrayPtr > Source/WTF/wtf/FastBitVector.h:163 > + uint32_t* m_array; Can't you use an OwnArrayPtr here, and save the manual management of this array's lifetime?
Landed with Oliver's suggestions in http://trac.webkit.org/changeset/115754
Merged in http://trac.webkit.org/changeset/117861
- It broke the 32 bit build, so I fixed it - http://trac.webkit.org/changeset/117905 - It made almost all tests crash on Qt, new bug report on it: https://bugs.webkit.org/show_bug.cgi?id=87082 - Could you check it, please?
(In reply to comment #5) > - It broke the 32 bit build, so I fixed it - http://trac.webkit.org/changeset/117905 > - It made almost all tests crash on Qt, new bug report on it: https://bugs.webkit.org/show_bug.cgi?id=87082 - Could you check it, please? Looking!
(In reply to comment #2) > (From update of attachment 139599 [details]) > View in context: https://bugs.webkit.org/attachment.cgi?id=139599&action=review > > r=me, but i'd prefer it if you made the m_array member of FastBitVector an OwnArrayPtr > > > Source/WTF/wtf/FastBitVector.h:163 > > + uint32_t* m_array; > > Can't you use an OwnArrayPtr here, and save the manual management of this array's lifetime? No, I can't, because OwnArrayPtr uses delete[].