Title: [193941] trunk/Source/_javascript_Core
Revision
193941
Author
fpi...@apple.com
Date
2015-12-10 19:41:18 -0800 (Thu, 10 Dec 2015)

Log Message

Consider still matching an address _expression_ even if B3 has already assigned a Tmp to it
https://bugs.webkit.org/show_bug.cgi?id=150777

Reviewed by Geoffrey Garen.

We need some heuristic for when an address should be computed as a separate instruction. It's
usually profitable to sink the address into the memory access. The previous heuristic meant that
the address would get separate instructions if it was in a separate block from the memory access.
This was messing up codegen of things like PutByVal out-of-bounds, where the address is computed
in one block and then used in another. I don't think that which block owns the address
computation should factor into any heuristic here, since it's so fragile: the compiler may lower
something by splitting blocks and we don't want this to ruin performance.

So, this replaces that heuristic with a more sensible one: the address computation gets its own
instruction if it has a lot of uses. In practice this means that we always sink the address
computation into the memory access.

* b3/B3LowerToAir.cpp:
(JSC::B3::Air::LowerToAir::effectiveAddr):

Modified Paths

Diff

Modified: trunk/Source/_javascript_Core/ChangeLog (193940 => 193941)


--- trunk/Source/_javascript_Core/ChangeLog	2015-12-11 02:24:09 UTC (rev 193940)
+++ trunk/Source/_javascript_Core/ChangeLog	2015-12-11 03:41:18 UTC (rev 193941)
@@ -1,3 +1,25 @@
+2015-12-10  Filip Pizlo  <fpi...@apple.com>
+
+        Consider still matching an address _expression_ even if B3 has already assigned a Tmp to it
+        https://bugs.webkit.org/show_bug.cgi?id=150777
+
+        Reviewed by Geoffrey Garen.
+
+        We need some heuristic for when an address should be computed as a separate instruction. It's
+        usually profitable to sink the address into the memory access. The previous heuristic meant that
+        the address would get separate instructions if it was in a separate block from the memory access.
+        This was messing up codegen of things like PutByVal out-of-bounds, where the address is computed
+        in one block and then used in another. I don't think that which block owns the address
+        computation should factor into any heuristic here, since it's so fragile: the compiler may lower
+        something by splitting blocks and we don't want this to ruin performance.
+
+        So, this replaces that heuristic with a more sensible one: the address computation gets its own
+        instruction if it has a lot of uses. In practice this means that we always sink the address
+        computation into the memory access.
+
+        * b3/B3LowerToAir.cpp:
+        (JSC::B3::Air::LowerToAir::effectiveAddr):
+
 2015-12-10  Daniel Bates  <daba...@apple.com>
 
         [CSP] eval() is not blocked for stringified literals

Modified: trunk/Source/_javascript_Core/b3/B3LowerToAir.cpp (193940 => 193941)


--- trunk/Source/_javascript_Core/b3/B3LowerToAir.cpp	2015-12-11 02:24:09 UTC (rev 193940)
+++ trunk/Source/_javascript_Core/b3/B3LowerToAir.cpp	2015-12-11 03:41:18 UTC (rev 193941)
@@ -369,9 +369,10 @@
     // This turns the given operand into an address.
     Arg effectiveAddr(Value* address)
     {
-        // FIXME: Consider matching an address _expression_ even if we've already assigned a
-        // Tmp to it. https://bugs.webkit.org/show_bug.cgi?id=150777
-        if (m_valueToTmp[address])
+        static const unsigned lotsOfUses = 10; // This is arbitrary and we should tune it eventually.
+        
+        // Only match if the address value isn't used in some large number of places.
+        if (m_useCounts.numUses(address) > lotsOfUses)
             return Arg::addr(tmp(address));
         
         switch (address->opcode()) {
_______________________________________________
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

Reply via email to