DFG::forAllKilledOperands() could use a faster bitvector scan in the same-inline...
authorfpizlo@apple.com <fpizlo@apple.com@268f45cc-cd09-0410-ab3c-d52691b4dbfc>
Mon, 12 Sep 2016 16:08:52 +0000 (16:08 +0000)
committerfpizlo@apple.com <fpizlo@apple.com@268f45cc-cd09-0410-ab3c-d52691b4dbfc>
Mon, 12 Sep 2016 16:08:52 +0000 (16:08 +0000)
commitc7ef3bf589c1c49ec5279c29e360cedcf5562de2
treee5312c9ff28b11f00daa22958fe91599266837b4
parentd802c163494251acdc63945293916f562e999b4d
DFG::forAllKilledOperands() could use a faster bitvector scan in the same-inline-stack fast path
https://bugs.webkit.org/show_bug.cgi?id=161849

Reviewed by Saam Barati.

Source/JavaScriptCore:

This is a fairly obvious change. This turns a loop that would query each bit individually
into a loop that will process a word at a time. I would expect a very tiny progression in
DFG compile times.

This also gave me an opportunity to test and fix the new FastBitVector functionality.

* dfg/DFGForAllKills.h:
(JSC::DFG::forAllKilledOperands):

Source/WTF:

It turns out that templates make private fields weird. FastBitVectorImpl can't necessarily
touch privates in instances of different template specializations of itself. So, I added a
public method called wordView() that exposes the necessary private field.

* wtf/FastBitVector.h:
(WTF::FastBitVectorImpl::operator&):
(WTF::FastBitVectorImpl::operator|):
(WTF::FastBitVectorImpl::operator~):
(WTF::FastBitVectorImpl::forEachSetBit):
(WTF::FastBitVectorImpl::wordView):

git-svn-id: https://svn.webkit.org/repository/webkit/trunk@205810 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Source/JavaScriptCore/ChangeLog
Source/JavaScriptCore/dfg/DFGForAllKills.h
Source/WTF/ChangeLog
Source/WTF/wtf/FastBitVector.h