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