Bug 161638 – GetMapBucket node should speculate on the type of its 'key' child

• Component: JavaScriptCore
• Status: RESOLVED FIXED

[Saam Barati]

We may already have proved the types of the incoming key into the GetMapBucket node, so we should take advantage of this.
Currently, we emit runtime checks for types, however, we could probably emit a less branchy loop if we know what the type of the
incoming key is.

[Saam Barati]

Looks like this is worth 2-3% on ES6SampleBench/Basic.

[Saam Barati]

Created attachment 290532 [details]
patch

[Filip Pizlo]

Comment on attachment 290532 [details]
patch

View in context: https://bugs.webkit.org/attachment.cgi?id=290532&action=review

> Source/JavaScriptCore/ftl/FTLLowerDFGToB3.cpp:6606
> +            m_out.insertNewBlocksBefore(notBitEqual);

It's scary to me that you're not capturing the return value here and resetting it...

> Source/JavaScriptCore/ftl/FTLLowerDFGToB3.cpp:6648
> +            m_out.appendTo(bucketKeyIsInt32, loopAround);

... down here.  Any reason why you don't do that?

[Filip Pizlo]

Comment on attachment 290532 [details]
patch

I think that aside from that minor thing, this code is right.

[Saam Barati]

Created attachment 290537 [details]
patch for landing

[Filip Pizlo]

Comment on attachment 290537 [details]
patch for landing

View in context: https://bugs.webkit.org/attachment.cgi?id=290537&action=review

> Source/JavaScriptCore/ftl/FTLLowerDFGToB3.cpp:6612
> +            m_out.appendTo(notBitEqual, bucketKeyIsCell);

This order: notBitEqual -> bucketKeyIsCell

is inconsistent with the order of allocation, above:

notBitEqual -> bucketKeyNotCell -> bucketKeyIsCell

I think that might confuse Output, at worst leading to a wonky block order.

[Saam Barati]

Comment on attachment 290537 [details]
patch for landing

View in context: https://bugs.webkit.org/attachment.cgi?id=290537&action=review

>> Source/JavaScriptCore/ftl/FTLLowerDFGToB3.cpp:6612
>> +            m_out.appendTo(notBitEqual, bucketKeyIsCell);
> 
> This order: notBitEqual -> bucketKeyIsCell
> 
> is inconsistent with the order of allocation, above:
> 
> notBitEqual -> bucketKeyNotCell -> bucketKeyIsCell
> 
> I think that might confuse Output, at worst leading to a wonky block order.

Ok. I'll re-order the allocations. Good catch.

[Saam Barati]

landed in:
https://trac.webkit.org/changeset/206763