Object allocation not sinking properly through CheckStructure
[WebKit-https.git] / Source / JavaScriptCore / ChangeLog
1 2015-05-04  Basile Clement  <basile_clement@apple.com>
2
3         Object allocation not sinking properly through CheckStructure
4         https://bugs.webkit.org/show_bug.cgi?id=144465
5
6         Reviewed by Filip Pizlo.
7
8         Currently, sinking an allocation through a CheckStructure will
9         completely ignore all structure checking, which is obviously wrong.
10
11         A CheckStructureImmediate node type was present for that purpose, but
12         the CheckStructures were not properly replaced.  This ensures that
13         CheckStructure nodes are replaced by CheckStructureImmediate nodes when
14         sunk through, and that structure checking happens correctly.
15
16         * dfg/DFGNode.h:
17         (JSC::DFG::Node::convertToCheckStructureImmediate): Added.
18         (JSC::DFG::Node::hasStructureSet):
19         * dfg/DFGObjectAllocationSinkingPhase.cpp:
20         (JSC::DFG::ObjectAllocationSinkingPhase::promoteSunkenFields):
21         * ftl/FTLLowerDFGToLLVM.cpp:
22         (JSC::FTL::LowerDFGToLLVM::compileCheckStructure):
23         (JSC::FTL::LowerDFGToLLVM::compileCheckStructureImmediate):
24         (JSC::FTL::LowerDFGToLLVM::checkStructure):
25         * tests/stress/sink_checkstructure.js: Added.
26         (foo):
27
28 2015-05-01  Geoffrey Garen  <ggaren@apple.com>
29
30         REGRESSION(r183570): jslib-traverse-jquery is 22% slower
31         https://bugs.webkit.org/show_bug.cgi?id=144476
32
33         Reviewed by Sam Weinig.
34
35         jslib-traverse-jquery is now 31% faster than its unregressed baseline.
36
37         The jQuery algorithm for sorting DOM nodes is so pathologically slow that,
38         to my knowledge, the topic of how to optimize it is not covered in any
39         literature about sorting.
40
41         On the slowest jQuery sorting test -- prevAll -- our new
42         Array.prototype.sort, compared to its predecessor, performed 12% fewer
43         comparisons and requireed 10X less overhead per comparison. Yet, it was
44         slower.
45
46         It was slower because it inadvertantly increased the average cost of the
47         comparison function by 2X. jQuery uses compareDocumentPosition to compare
48         DOM nodes, and compareDocumentPosition(a, b) is O(N) in the distance
49         required to traverse backwards from b to a. In prevAll, we encounter the
50         worst case for merge sort of compareDocumentPosition: A long list of DOM
51         nodes in mostly reverse order. In this case, merge sort will sequentially
52         compareDocumentPosition(a, b), where a is not reachable backwards from
53         b, and therefore compareDocumentPosition will traverse the whole sibling
54         list.
55
56         The solution is simple enough: Call compareDocumentPosition(b, a) instead.
57
58         This is a pretty silly thing to do, but it is harmless, and jQuery is
59         popular, so let's do it.
60
61         We do not risk suffering the same problem in reverse when sorting a long
62         list of DOM nodes in forward order. (We still have a 37% speedup on the
63         nextAll benchmark.) The reason is that merge sort performs 2X fewer
64         comparisons when the list is already sorted, so we can worry less about
65         the cost of each comparison.
66
67         A fully principled soultion to this problem would probably do something
68         like Python's timsort, which special-cases ordered ranges to perform
69         only O(n) comparisons. But that would contradict our original
70         goal of just having something simple that works.
71
72         Another option is for elements to keep a compareDocumentPosition cache,
73         like a node list cache, which allows you to determine the absolute
74         position of a node using a hash lookup. I will leave this as an exercise
75         for kling.
76
77         * builtins/Array.prototype.js:
78         (sort.merge): Compare in an order that is favorable to a comparator
79         that calls compareDocumentPosition.
80
81 2015-05-04  Csaba Osztrogon√°c  <ossy@webkit.org>
82
83         [cmake] Fix generate-js-builtins related incremental build issue
84         https://bugs.webkit.org/show_bug.cgi?id=144094
85
86         Reviewed by Michael Saboff.
87
88         * CMakeLists.txt: Generated JSCBuiltins.<cpp|h> should depend on Source/JavaScriptCore/builtins directory.
89         Pass input directory to generate-js-builtins instead of Source/JavaScriptCore/builtins/*.js.
90         * DerivedSources.make:
91         Pass input directory to generate-js-builtins instead of Source/JavaScriptCore/builtins/*.js.
92         * generate-js-builtins: Accept input files and input directory too.
93
94 2015-05-03  Simon Fraser  <simon.fraser@apple.com>
95
96         Make some static data const
97         https://bugs.webkit.org/show_bug.cgi?id=144552
98
99         Reviewed by Andreas Kling.
100         
101         Turn characterSetInfo into const data.
102
103         * yarr/YarrCanonicalizeUCS2.cpp:
104         * yarr/YarrCanonicalizeUCS2.h:
105
106 2015-05-01  Filip Pizlo  <fpizlo@apple.com>
107
108         TypeOf should be fast
109         https://bugs.webkit.org/show_bug.cgi?id=144396
110
111         Reviewed by Geoffrey Garen.
112         
113         Adds comprehensive support for fast typeof to the optimizing JITs. Calls into the runtime
114         are only used for very exotic objects - they must have either the MasqueradesAsUndefined or
115         TypeOfShouldCallGetCallData type flags set. All other cases are handled inline.
116         
117         This means optimizing IsObjectOrNull, IsFunction, and TypeOf - all node types that used to
118         rely heavily on C++ calls to fulfill their function.
119         
120         Because TypeOf is now so fast, we no longer need to do any speculations on this node.
121         
122         In the FTL, we take this further by querying AI for each branch in the TypeOf decision tree.
123         This means that if the TypeOf is dominated by any type checks, we will automatically prune
124         out cases that are redundant.
125         
126         This patch anticipates the addition of SwitchTypeOf or something like that. So, the TypeOf
127         code generation is designed to be reusable.
128         
129         This is a speed-up on most typeof benchmarks. But, it is a slow-down on benchmarks that take
130         the exotic call trap hook. That hook is now in a deeper slow path than before.
131
132         * CMakeLists.txt:
133         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
134         * JavaScriptCore.xcodeproj/project.pbxproj:
135         * dfg/DFGClobberize.h:
136         (JSC::DFG::clobberize): TypeOf was pure all along, but we failed to realize this.
137         * dfg/DFGFixupPhase.cpp:
138         (JSC::DFG::FixupPhase::fixupNode):
139         * dfg/DFGHeapLocation.cpp:
140         (WTF::printInternal):
141         * dfg/DFGHeapLocation.h:
142         * dfg/DFGOperations.cpp:
143         * dfg/DFGOperations.h:
144         * dfg/DFGSpeculativeJIT.cpp:
145         (JSC::DFG::SpeculativeJIT::compileIsObjectOrNull):
146         (JSC::DFG::SpeculativeJIT::compileIsFunction):
147         (JSC::DFG::SpeculativeJIT::compileTypeOf):
148         * dfg/DFGSpeculativeJIT.h:
149         (JSC::DFG::SpeculativeJIT::blessedBooleanResult):
150         (JSC::DFG::SpeculativeJIT::callOperation):
151         * dfg/DFGSpeculativeJIT32_64.cpp:
152         (JSC::DFG::SpeculativeJIT::compile):
153         * dfg/DFGSpeculativeJIT64.cpp:
154         (JSC::DFG::SpeculativeJIT::compile):
155         * ftl/FTLCapabilities.cpp:
156         (JSC::FTL::canCompile):
157         * ftl/FTLIntrinsicRepository.h:
158         * ftl/FTLLowerDFGToLLVM.cpp:
159         (JSC::FTL::LowerDFGToLLVM::compileNode):
160         (JSC::FTL::LowerDFGToLLVM::compileIsObjectOrNull):
161         (JSC::FTL::LowerDFGToLLVM::compileIsFunction):
162         (JSC::FTL::LowerDFGToLLVM::compileTypeOf):
163         (JSC::FTL::LowerDFGToLLVM::buildTypeOf): Reusable TypeOf building for the FTL.
164         (JSC::FTL::LowerDFGToLLVM::isExoticForTypeof):
165         * ftl/FTLSwitchCase.h:
166         (JSC::FTL::SwitchCase::SwitchCase):
167         * jit/AssemblyHelpers.h:
168         (JSC::AssemblyHelpers::branchIfNotEqual):
169         (JSC::AssemblyHelpers::branchIfEqual):
170         (JSC::AssemblyHelpers::branchIfNumber):
171         (JSC::AssemblyHelpers::branchIfNotNumber):
172         (JSC::AssemblyHelpers::branchIfBoolean):
173         (JSC::AssemblyHelpers::branchIfNotBoolean):
174         (JSC::AssemblyHelpers::boxBooleanPayload):
175         (JSC::AssemblyHelpers::boxBoolean):
176         (JSC::AssemblyHelpers::emitTypeOf): Reusable TypeOf building for assembly JITs.
177         * jit/JITOperations.h:
178         * runtime/SmallStrings.h:
179         (JSC::SmallStrings::typeString):
180         * runtime/TypeofType.cpp: Added.
181         (WTF::printInternal):
182         * runtime/TypeofType.h: Added.
183         * tests/stress/type-of-functions-and-objects.js: Modified this test to give more comprehensive feedback.
184
185 2015-05-02  Filip Pizlo  <fpizlo@apple.com>
186
187         Unreviewed, add a FIXME referencing https://bugs.webkit.org/show_bug.cgi?id=144527.
188
189         * dfg/DFGLICMPhase.cpp:
190         (JSC::DFG::LICMPhase::attemptHoist):
191
192 2015-05-02  Filip Pizlo  <fpizlo@apple.com>
193
194         Unreviewed, add FIXMEs referencing https://bugs.webkit.org/show_bug.cgi?id=144524 and
195         https://bugs.webkit.org/show_bug.cgi?id=144525.
196
197         * dfg/DFGLICMPhase.cpp:
198         (JSC::DFG::LICMPhase::attemptHoist):
199         * dfg/DFGPhantomInsertionPhase.cpp:
200
201 2015-05-02  Yusuke Suzuki  <utatane.tea@gmail.com>
202
203         Static property hashtable should only lookup with non-symbol key
204         https://bugs.webkit.org/show_bug.cgi?id=144438
205
206         Reviewed by Darin Adler.
207
208         Static property hashtable compares the Identifier's uid
209         with the normal C string without interning it.
210         So this comparison is performed in their contents.
211         As the result, in this comparison, symbol-ness is not considered.
212
213         So if accidentally the hash collision occur with the symbol and the string
214         and they have the same contents, the hash table entry is looked up incorrectly.
215
216         * runtime/Lookup.h:
217         (JSC::HashTable::entry):
218
219 2015-05-01  Ryosuke Niwa  <rniwa@webkit.org>
220
221         Class syntax should allow string and numeric identifiers for method names
222         https://bugs.webkit.org/show_bug.cgi?id=144254
223
224         Reviewed by Darin Adler.
225
226         Added the support for string and numeric identifiers in class syntax.
227
228         * parser/Parser.cpp:
229         (JSC::Parser<LexerType>::parseFunctionInfo): Instead of using ConstructorKind to indicate whether we're
230         inside a class or not, use the newly added SuperBinding argument instead. ConstructorKind is now None
231         outside a class constructor as it should be.
232         (JSC::Parser<LexerType>::parseFunctionDeclaration):
233         (JSC::Parser<LexerType>::parseClass): No longer expects an identifier at the beginning of every class
234         element to allow numeric and string method names. For both of those method names, parse it here instead
235         of parseFunctionInfo since it doesn't support either type. Also pass in SuperBinding::Needed.
236         (JSC::Parser<LexerType>::parsePropertyMethod): Call parseFunctionInfo with SuperBinding::NotNeeded since
237         this function is never used to parse a class method.
238         (JSC::Parser<LexerType>::parseGetterSetter): Pass in superBinding argument to parseFunctionInfo.
239         (JSC::Parser<LexerType>::parsePrimaryExpression): Call parseFunctionInfo with SuperBinding::NotNeeded.
240         * parser/Parser.h:
241         * parser/SyntaxChecker.h:
242         (JSC::SyntaxChecker::createProperty):
243
244 2015-05-01  Filip Pizlo  <fpizlo@apple.com>
245
246         FTL should use AI more
247         https://bugs.webkit.org/show_bug.cgi?id=144500
248
249         Reviewed by Oliver Hunt.
250         
251         This makes our type check folding even more comprehensive by ensuring that even if the FTL
252         decides to emit some checks, it will still do another query to the abstract interpreter to
253         see if the check is necessary. This helps with cases where we decided early on to speculate
254         one way, but later proved a more specific type of the value in question, and the constant
255         folder didn't catch it.
256         
257         This also makes it more natural to query the abstract interpreter. For example, if you just
258         want the proven type, you can now say provenType(node) or provenType(edge).
259
260         * dfg/DFGArrayMode.cpp:
261         (JSC::DFG::ArrayMode::alreadyChecked):
262         * dfg/DFGArrayMode.h:
263         * ftl/FTLLowerDFGToLLVM.cpp:
264         (JSC::FTL::LowerDFGToLLVM::compileBooleanToNumber):
265         (JSC::FTL::LowerDFGToLLVM::compileToThis):
266         (JSC::FTL::LowerDFGToLLVM::compileValueAdd):
267         (JSC::FTL::LowerDFGToLLVM::compileArithAddOrSub):
268         (JSC::FTL::LowerDFGToLLVM::compileArithPow):
269         (JSC::FTL::LowerDFGToLLVM::compileArithNegate):
270         (JSC::FTL::LowerDFGToLLVM::compileGetById):
271         (JSC::FTL::LowerDFGToLLVM::compileCheckArray):
272         (JSC::FTL::LowerDFGToLLVM::compilePutByVal):
273         (JSC::FTL::LowerDFGToLLVM::compileToStringOrCallStringConstructor):
274         (JSC::FTL::LowerDFGToLLVM::compileToPrimitive):
275         (JSC::FTL::LowerDFGToLLVM::compileStringCharAt):
276         (JSC::FTL::LowerDFGToLLVM::compileStringCharCodeAt):
277         (JSC::FTL::LowerDFGToLLVM::compileCompareStrictEq):
278         (JSC::FTL::LowerDFGToLLVM::compileSwitch):
279         (JSC::FTL::LowerDFGToLLVM::compileIsBoolean):
280         (JSC::FTL::LowerDFGToLLVM::compileIsNumber):
281         (JSC::FTL::LowerDFGToLLVM::compileIsString):
282         (JSC::FTL::LowerDFGToLLVM::compileIsObject):
283         (JSC::FTL::LowerDFGToLLVM::compileInstanceOf):
284         (JSC::FTL::LowerDFGToLLVM::numberOrNotCellToInt32):
285         (JSC::FTL::LowerDFGToLLVM::baseIndex):
286         (JSC::FTL::LowerDFGToLLVM::compareEqObjectOrOtherToObject):
287         (JSC::FTL::LowerDFGToLLVM::typedArrayLength):
288         (JSC::FTL::LowerDFGToLLVM::boolify):
289         (JSC::FTL::LowerDFGToLLVM::equalNullOrUndefined):
290         (JSC::FTL::LowerDFGToLLVM::lowInt32):
291         (JSC::FTL::LowerDFGToLLVM::lowInt52):
292         (JSC::FTL::LowerDFGToLLVM::lowCell):
293         (JSC::FTL::LowerDFGToLLVM::lowBoolean):
294         (JSC::FTL::LowerDFGToLLVM::lowDouble):
295         (JSC::FTL::LowerDFGToLLVM::isCellOrMisc):
296         (JSC::FTL::LowerDFGToLLVM::isNotCellOrMisc):
297         (JSC::FTL::LowerDFGToLLVM::isNumber):
298         (JSC::FTL::LowerDFGToLLVM::isNotNumber):
299         (JSC::FTL::LowerDFGToLLVM::isNotCell):
300         (JSC::FTL::LowerDFGToLLVM::isCell):
301         (JSC::FTL::LowerDFGToLLVM::isNotMisc):
302         (JSC::FTL::LowerDFGToLLVM::isMisc):
303         (JSC::FTL::LowerDFGToLLVM::isNotBoolean):
304         (JSC::FTL::LowerDFGToLLVM::isBoolean):
305         (JSC::FTL::LowerDFGToLLVM::isNotOther):
306         (JSC::FTL::LowerDFGToLLVM::isOther):
307         (JSC::FTL::LowerDFGToLLVM::isProvenValue):
308         (JSC::FTL::LowerDFGToLLVM::isObject):
309         (JSC::FTL::LowerDFGToLLVM::isNotObject):
310         (JSC::FTL::LowerDFGToLLVM::isNotString):
311         (JSC::FTL::LowerDFGToLLVM::isString):
312         (JSC::FTL::LowerDFGToLLVM::isFunction):
313         (JSC::FTL::LowerDFGToLLVM::isNotFunction):
314         (JSC::FTL::LowerDFGToLLVM::speculateObjectOrOther):
315         (JSC::FTL::LowerDFGToLLVM::speculateStringObjectForStructureID):
316         (JSC::FTL::LowerDFGToLLVM::speculateNotStringVar):
317         (JSC::FTL::LowerDFGToLLVM::abstractValue):
318         (JSC::FTL::LowerDFGToLLVM::provenType):
319         (JSC::FTL::LowerDFGToLLVM::provenValue):
320         (JSC::FTL::LowerDFGToLLVM::abstractStructure):
321
322 2015-05-01  Martin Robinson  <mrobinson@igalia.com>
323
324         USE(...) macro should expect unprefixed variables
325         https://bugs.webkit.org/show_bug.cgi?id=144454
326
327         Reviewed by Daniel Bates.
328
329         * CMakeLists.txt: Replace all occurrences WTF_USE with USE.
330
331 2015-05-01  Jordan Harband  <ljharb@gmail.com>
332
333         String#startsWith/endsWith/includes don't handle Infinity position/endPosition args correctly
334         https://bugs.webkit.org/show_bug.cgi?id=144314
335
336         Reviewed by Darin Adler.
337
338         Fixing handling of Infinity position args, per
339         https://people.mozilla.org/~jorendorff/es6-draft.html#sec-string.prototype.includes
340         https://people.mozilla.org/~jorendorff/es6-draft.html#sec-string.prototype.startswith
341         https://people.mozilla.org/~jorendorff/es6-draft.html#sec-string.prototype.endswith
342
343         * runtime/StringPrototype.cpp:
344         (JSC::clampInt32):
345         (JSC::stringProtoFuncStartsWith):
346         (JSC::stringProtoFuncEndsWith):
347         (JSC::stringProtoFuncIncludes):
348
349 2015-05-01  Basile Clement  <basile_clement@apple.com>
350
351         Math.abs() returns negative
352         https://bugs.webkit.org/show_bug.cgi?id=137827
353
354         Reviewed by Michael Saboff.
355
356         Math.abs() on doubles was mistakenly assumed by the DFG AI to be the
357         identity function.
358
359         * dfg/DFGAbstractInterpreterInlines.h:
360         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
361         * tests/stress/math-abs-positive.js: Added, was previously failing.
362         (foo):
363
364 2015-05-01  Basile Clement  <basile_clement@apple.com>
365
366         Function allocation sinking shouldn't be performed on singleton functions
367         https://bugs.webkit.org/show_bug.cgi?id=144166
368
369         Reviewed by Geoffrey Garen.
370
371         Function allocations usually are free of any other side effects, but
372         this is not the case for allocations performed while the underlying
373         FunctionExecutable is still a singleton (as this allogation will fire
374         watchpoints invalidating code that depends on it being a singleton).
375         As the object allocation sinking phase assumes object allocation is
376         free of side-effects, sinking these allocations is not correct.
377
378         This also means that when materializing a function allocation on OSR
379         exit, that function's executable will never be a singleton, and we don't have
380         to worry about its watchpoint, allowing us to use
381         JSFunction::createWithInvalidatedRellocationWatchpoint instead of
382         JSFunction::create.
383
384         * dfg/DFGObjectAllocationSinkingPhase.cpp:
385         (JSC::DFG::ObjectAllocationSinkingPhase::handleNode):
386         * ftl/FTLOperations.cpp:
387         (JSC::FTL::operationMaterializeObjectInOSR):
388
389 2015-04-30  Jon Davis  <jond@apple.com>
390
391         Web Inspector: console should show an icon for console.info() messages
392         https://bugs.webkit.org/show_bug.cgi?id=18530
393
394         Reviewed by Timothy Hatcher.
395
396         * inspector/ConsoleMessage.cpp:
397         (Inspector::messageLevelValue):
398         * inspector/protocol/Console.json:
399         * runtime/ConsoleClient.cpp:
400         (JSC::appendMessagePrefix):
401         * runtime/ConsolePrototype.cpp:
402         (JSC::ConsolePrototype::finishCreation):
403         (JSC::consoleProtoFuncInfo):
404         * runtime/ConsoleTypes.h:
405
406 2015-04-30  Filip Pizlo  <fpizlo@apple.com>
407
408         Move all of the branchIs<type> helpers from SpeculativeJIT into AssemblyHelpers
409         https://bugs.webkit.org/show_bug.cgi?id=144462
410
411         Reviewed by Geoffrey Garen and Mark Lam.
412         
413         At some point we started adding representation-agnostic helpers for doing common type tests.
414         We added some in SpeculativeJIT, and then some in AssemblyHelpers. Prior to this change,
415         they had overlapping powers, though SpeculativeJIT was a bit better.
416         
417         This removes SpeculativeJIT's helpers and strengthens AssemblyHelpers' helpers. This is
418         better because now all of these helpers can be used in all of the assembly-based JITs, not
419         just the DFG. It also settles on what I find to be a slightly better naming convention.
420         For example where we previously would have said branchIsString, now we say
421         branchIfString. Similarly, branchNotString becomes branchIfNotString.
422
423         * dfg/DFGSpeculativeJIT.cpp:
424         (JSC::DFG::SpeculativeJIT::compilePeepHoleObjectEquality):
425         (JSC::DFG::SpeculativeJIT::compileValueToInt32):
426         (JSC::DFG::SpeculativeJIT::compileInstanceOfForObject):
427         (JSC::DFG::SpeculativeJIT::compileInstanceOf):
428         (JSC::DFG::SpeculativeJIT::compileStringToUntypedEquality):
429         (JSC::DFG::SpeculativeJIT::compileStringIdentToNotStringVarEquality):
430         (JSC::DFG::SpeculativeJIT::compileGetByValOnScopedArguments):
431         (JSC::DFG::SpeculativeJIT::compileToStringOrCallStringConstructorOnCell):
432         (JSC::DFG::SpeculativeJIT::speculateObject):
433         (JSC::DFG::SpeculativeJIT::speculateObjectOrOther):
434         (JSC::DFG::SpeculativeJIT::speculateString):
435         (JSC::DFG::SpeculativeJIT::speculateNotStringVar):
436         (JSC::DFG::SpeculativeJIT::speculateNotCell):
437         (JSC::DFG::SpeculativeJIT::speculateOther):
438         (JSC::DFG::SpeculativeJIT::emitSwitchChar):
439         (JSC::DFG::SpeculativeJIT::emitSwitchString):
440         (JSC::DFG::SpeculativeJIT::branchIsObject): Deleted.
441         (JSC::DFG::SpeculativeJIT::branchNotObject): Deleted.
442         (JSC::DFG::SpeculativeJIT::branchIsString): Deleted.
443         (JSC::DFG::SpeculativeJIT::branchNotString): Deleted.
444         * dfg/DFGSpeculativeJIT.h:
445         * dfg/DFGSpeculativeJIT32_64.cpp:
446         (JSC::DFG::SpeculativeJIT::nonSpeculativeNonPeepholeCompareNull):
447         (JSC::DFG::SpeculativeJIT::nonSpeculativePeepholeBranchNull):
448         (JSC::DFG::SpeculativeJIT::emitCall):
449         (JSC::DFG::SpeculativeJIT::fillSpeculateCell):
450         (JSC::DFG::SpeculativeJIT::compileObjectEquality):
451         (JSC::DFG::SpeculativeJIT::compileObjectToObjectOrOtherEquality):
452         (JSC::DFG::SpeculativeJIT::compilePeepHoleObjectToObjectOrOtherEquality):
453         (JSC::DFG::SpeculativeJIT::compileObjectOrOtherLogicalNot):
454         (JSC::DFG::SpeculativeJIT::emitObjectOrOtherBranch):
455         (JSC::DFG::SpeculativeJIT::compile):
456         (JSC::DFG::SpeculativeJIT::branchIsCell): Deleted.
457         (JSC::DFG::SpeculativeJIT::branchNotCell): Deleted.
458         (JSC::DFG::SpeculativeJIT::branchIsOther): Deleted.
459         (JSC::DFG::SpeculativeJIT::branchNotOther): Deleted.
460         * dfg/DFGSpeculativeJIT64.cpp:
461         (JSC::DFG::SpeculativeJIT::nonSpeculativeNonPeepholeCompareNull):
462         (JSC::DFG::SpeculativeJIT::nonSpeculativePeepholeBranchNull):
463         (JSC::DFG::SpeculativeJIT::fillSpeculateCell):
464         (JSC::DFG::SpeculativeJIT::compileObjectEquality):
465         (JSC::DFG::SpeculativeJIT::compileObjectToObjectOrOtherEquality):
466         (JSC::DFG::SpeculativeJIT::compilePeepHoleObjectToObjectOrOtherEquality):
467         (JSC::DFG::SpeculativeJIT::compileObjectOrOtherLogicalNot):
468         (JSC::DFG::SpeculativeJIT::emitObjectOrOtherBranch):
469         (JSC::DFG::SpeculativeJIT::compile):
470         (JSC::DFG::SpeculativeJIT::writeBarrier):
471         (JSC::DFG::SpeculativeJIT::branchIsCell): Deleted.
472         (JSC::DFG::SpeculativeJIT::branchNotCell): Deleted.
473         (JSC::DFG::SpeculativeJIT::branchIsOther): Deleted.
474         (JSC::DFG::SpeculativeJIT::branchNotOther): Deleted.
475         * jit/AssemblyHelpers.h:
476         (JSC::AssemblyHelpers::branchIfCell):
477         (JSC::AssemblyHelpers::branchIfOther):
478         (JSC::AssemblyHelpers::branchIfNotOther):
479         (JSC::AssemblyHelpers::branchIfObject):
480         (JSC::AssemblyHelpers::branchIfNotObject):
481         (JSC::AssemblyHelpers::branchIfType):
482         (JSC::AssemblyHelpers::branchIfNotType):
483         (JSC::AssemblyHelpers::branchIfString):
484         (JSC::AssemblyHelpers::branchIfNotString):
485         (JSC::AssemblyHelpers::branchIfSymbol):
486         (JSC::AssemblyHelpers::branchIfNotSymbol):
487         (JSC::AssemblyHelpers::branchIfFunction):
488         (JSC::AssemblyHelpers::branchIfNotFunction):
489         (JSC::AssemblyHelpers::branchIfEmpty):
490         (JSC::AssemblyHelpers::branchIsEmpty): Deleted.
491         (JSC::AssemblyHelpers::branchIfCellNotObject): Deleted.
492         * jit/JITPropertyAccess.cpp:
493         (JSC::JIT::emitScopedArgumentsGetByVal):
494
495 2015-04-30  Filip Pizlo  <fpizlo@apple.com>
496
497         js/regress/is-string-fold-tricky.html and js/regress/is-string-fold.html are crashing
498         https://bugs.webkit.org/show_bug.cgi?id=144463
499
500         Reviewed by Benjamin Poulain.
501         
502         Fixup phase was super cleverly folding an IsString(@x) when @x is predicted SpecString
503         into a Check(String:@x) followed by JSConstant(true). Then in these tests the
504         ValueAdd(IsString(@x), @stuff) would try to turn this into an integer add by cleverly
505         converting the boolean into an integer. But as part of doing that, it would try to
506         short-circuit any profiling by leveraging the fact that the IsString is now a constant,
507         and it would try to figure out if the addition might overflow. Part of that logic
508         involved checking if the immediate is either a boolean or a sufficiently small integer.
509         But: it would check if it's a sufficiently small integer before checking if it was a
510         boolean, so it would try to call asNumber() on the boolean.
511         
512         All of this cleverness was very deliberate, but apparently the @stuff + booleanConstant
513         case was previously never hit until I wrote these tests, and so we never knew that
514         calling asNumber() on a boolean was wrong.
515         
516         The fix is super simple: the expression should just check for boolean first.
517         
518         This bug was benign in release builds. JSValue::asNumber() on a boolean would return
519         garbage, and that's OK, since we'd take the boolean case anyway.
520
521         * dfg/DFGGraph.h:
522         (JSC::DFG::Graph::addImmediateShouldSpeculateInt32):
523
524 2015-04-30  Filip Pizlo  <fpizlo@apple.com>
525
526         Unreviewed, add a FIXME comment referencing https://bugs.webkit.org/show_bug.cgi?id=144458.
527
528         * jit/JITOperations.cpp:
529
530 2015-04-30  Filip Pizlo  <fpizlo@apple.com>
531
532         Add a comment clarifying the behavior and semantics of getCallData/getConstructData, in
533         particular that they cannot change their minds and may be called from compiler threads.
534
535         Rubber stamped by Geoffrey Garen.
536
537         * runtime/JSCell.h:
538
539 2015-04-29  Filip Pizlo  <fpizlo@apple.com>
540
541         DFG Is<Blah> versions of TypeOf should fold based on proven input type
542         https://bugs.webkit.org/show_bug.cgi?id=144409
543
544         Reviewed by Geoffrey Garen.
545         
546         We were missing some obvious folding opportunities here. I don't know how this affects real
547         code, but in general, we like to ensure that our constant folding is comprehensive. So this
548         is more about placating my static analysis OCD than anything else.
549         
550         I added a bunch of speed/correctness tests for this in LayoutTests/js/regress.
551
552         * dfg/DFGAbstractInterpreterInlines.h:
553         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
554
555 2015-04-30  Yusuke Suzuki  <utatane.tea@gmail.com>
556
557         Use the default hash value for Symbolized StringImpl
558         https://bugs.webkit.org/show_bug.cgi?id=144347
559
560         Reviewed by Darin Adler.
561
562         Before this patch, symbolized StringImpl* has a special hash value
563         to avoid the hash collision with the other normal StringImpl*.
564         I guess that it is introduced when private symbols are introduced.
565         However, it prevents using symbolized StringImpl* in the other place
566         For example, using it as WTFString cause a problem because of its special hash value.
567
568         When only using private symbols, they are not exposed to the outside of JSC,
569         so we can handle it carefully. But now, it's extended to symbols.
570         So I think storing a special hash value in StringImpl* causes an error.
571
572         To avoid this, I propose using the usual hash value in symbolized StringImpl*.
573         And to provide significantly different hash value when using it as symbol,
574         store the additional hash value in symbolized StringImpl*. It is used when
575         the hash value is required by IdentifierRepHash.
576
577         * runtime/Identifier.h:
578         (JSC::IdentifierRepHash::hash):
579         * runtime/Lookup.h:
580         (JSC::HashTable::entry):
581         * runtime/PropertyMapHashTable.h:
582         (JSC::PropertyTable::find):
583         (JSC::PropertyTable::get):
584         * runtime/Structure.cpp:
585         (JSC::PropertyTable::checkConsistency):
586
587 2015-04-29  Benjamin Poulain  <bpoulain@apple.com>
588
589         [JSC] Remove RageConvert array conversion
590         https://bugs.webkit.org/show_bug.cgi?id=144433
591
592         Reviewed by Filip Pizlo.
593
594         RageConvert was causing a subtle bug that was hitting the Kraken crypto tests
595         pretty hard:
596         -The indexing types shows that the array access varies between Int32 and DoubleArray.
597         -ArrayMode::fromObserved() decided to use the most generic type: DoubleArray.
598          An Arrayify node would convert the Int32 to that type.
599         -Somewhere, a GetByVal or PutByVal would have the flag NodeBytecodeUsesAsInt. That
600          node would use RageConvert instead of Convert.
601         -The Arrayify for that GetByVal with RageConvert would not convert the array to
602          Contiguous.
603         -All the following array access that do not have the flag NodeBytecodeUsesAsInt would
604          now expect a DoubleArray and always get a Contiguous Array. The CheckStructure
605          fail systematically and we never get to run the later code.
606
607         Getting rid of RageConvert fixes the problem and does not seems to have any
608         negative side effect on other benchmarks.
609
610         The improvments on Kraken are:
611             -stanford-crypto-aes: definitely 1.0915x faster.
612             -stanford-crypto-pbkdf2: definitely 1.2446x faster.
613             -stanford-crypto-sha256-iterative: definitely 1.0544x faster.
614
615         * dfg/DFGAbstractInterpreterInlines.h:
616         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
617         * dfg/DFGArrayMode.cpp:
618         (JSC::DFG::ArrayMode::refine):
619         (JSC::DFG::arrayConversionToString):
620         * dfg/DFGArrayMode.h:
621         * dfg/DFGArrayifySlowPathGenerator.h:
622         * dfg/DFGFixupPhase.cpp:
623         (JSC::DFG::FixupPhase::fixupNode):
624         * dfg/DFGOperations.cpp:
625         * dfg/DFGOperations.h:
626         * dfg/DFGPredictionPropagationPhase.cpp:
627         (JSC::DFG::PredictionPropagationPhase::propagate):
628         * dfg/DFGTypeCheckHoistingPhase.cpp:
629         (JSC::DFG::TypeCheckHoistingPhase::identifyRedundantStructureChecks):
630         * ftl/FTLLowerDFGToLLVM.cpp:
631         (JSC::FTL::LowerDFGToLLVM::compileArrayifyToStructure):
632         * runtime/JSObject.cpp:
633         (JSC::JSObject::convertDoubleToContiguous):
634         (JSC::JSObject::ensureContiguousSlow):
635         (JSC::JSObject::genericConvertDoubleToContiguous): Deleted.
636         (JSC::JSObject::rageConvertDoubleToContiguous): Deleted.
637         (JSC::JSObject::rageEnsureContiguousSlow): Deleted.
638         * runtime/JSObject.h:
639         (JSC::JSObject::rageEnsureContiguous): Deleted.
640
641 2015-04-29  Joseph Pecoraro  <pecoraro@apple.com>
642
643         Gracefully handle missing auto pause key on remote inspector setup
644         https://bugs.webkit.org/show_bug.cgi?id=144411
645
646         Reviewed by Timothy Hatcher.
647
648         * inspector/remote/RemoteInspector.mm:
649         (Inspector::RemoteInspector::receivedSetupMessage):
650
651 2015-04-29  Joseph Pecoraro  <pecoraro@apple.com>
652
653         NodeList has issues with Symbol and empty string
654         https://bugs.webkit.org/show_bug.cgi?id=144310
655
656         Reviewed by Darin Adler.
657
658         * runtime/PropertyName.h:
659         (JSC::PropertyName::isSymbol):
660         Helper to check if the PropertyName is a string or symbol property.
661
662 2015-04-29  Alex Christensen  <achristensen@webkit.org>
663
664         Fix non-cygwin incremental builds on Windows.
665         https://bugs.webkit.org/show_bug.cgi?id=143264
666
667         Reviewed by Brent Fulgham.
668
669         * generate-js-builtins:
670         Remove stale headers before calling os.rename to replace them.
671
672 2015-04-29  Filip Pizlo  <fpizlo@apple.com>
673
674         JSTypeInfo should have an inline type flag to indicate of getCallData() has been overridden
675         https://bugs.webkit.org/show_bug.cgi?id=144397
676
677         Reviewed by Andreas Kling.
678         
679         Add the flag to JSTypeInfo. It's an inline flag so that it's fast to query. Slap the flag on
680         callback objects and internal functions. Modify the TypeOf operation to use this flag to avoid
681         making a getCallData() call if it isn't necessary.
682
683         * API/JSCallbackObject.h:
684         * runtime/InternalFunction.h:
685         * runtime/JSTypeInfo.h:
686         (JSC::TypeInfo::typeOfShouldCallGetCallData):
687         * runtime/Operations.cpp:
688         (JSC::jsTypeStringForValue):
689         * tests/stress/type-of-functions-and-objects.js: Added.
690         (foo):
691         (bar):
692         (baz):
693         (fuzz):
694         (expect):
695         (test):
696
697 2015-04-28  Geoffrey Garen  <ggaren@apple.com>
698
699         It shouldn't take 1846 lines of code and 5 FIXMEs to sort an array.
700         https://bugs.webkit.org/show_bug.cgi?id=144013
701
702         Reviewed by Mark Lam.
703
704         This patch implements Array.prototype.sort in JavaScript, removing the
705         C++ implementations. It is simpler and less error-prone to express our
706         operations in JavaScript, which provides memory safety, exception safety,
707         and recursion safety.
708
709         The performance result is mixed, but net positive in my opinion. It's
710         difficult to enumerate all the results, since we used to have so many
711         different sorting modes, and there are lots of different data patterns
712         across which you might want to measure sorting. Suffice it to say:
713
714             (*) The benchmarks we track are faster or unchanged.
715
716             (*) Sorting random input using a comparator -- which we think is
717             common -- is 3X faster.
718
719             (*) Sorting random input in a non-array object -- which jQuery does
720             -- is 4X faster.
721
722             (*) Sorting random input in a compact array of integers using a
723             trivial pattern-matchable comparator is 2X *slower*.
724
725         * builtins/Array.prototype.js:
726         (sort.min):
727         (sort.stringComparator):
728         (sort.compactSparse): Special case compaction for sparse arrays because
729         we don't want to hang when sorting new Array(BIG).
730
731         (sort.compact):
732         (sort.merge):
733         (sort.mergeSort): Use merge sort because it's a reasonably efficient
734         stable sort. We have evidence that some sites depend on stable sort,
735         even though the ES6 spec does not mandate it. (See
736         <http://trac.webkit.org/changeset/33967>.)
737
738         This is a textbook implementation of merge sort with three optimizations:
739
740             (1) Use iteration instead of recursion;
741
742             (2) Use array subscripting instead of array copying in order to
743             create logical sub-lists without creating physical sub-lists;
744
745             (3) Swap src and dst at each iteration instead of copying src into
746             dst, and only copy src into the subject array at the end if src is
747             not the subject array.
748
749         (sort.inflate):
750         (sort.comparatorSort):
751         (sort): Sort in JavaScript for the win.
752
753         * builtins/BuiltinExecutables.cpp:
754         (JSC::BuiltinExecutables::createExecutableInternal): Allow non-private
755         names so we can use helper functions.
756
757         * bytecode/CodeBlock.h:
758         (JSC::CodeBlock::isNumericCompareFunction): Deleted.
759         * bytecode/UnlinkedCodeBlock.cpp:
760         (JSC::UnlinkedCodeBlock::UnlinkedCodeBlock):
761         * bytecode/UnlinkedCodeBlock.h:
762         (JSC::UnlinkedCodeBlock::setIsNumericCompareFunction): Deleted.
763         (JSC::UnlinkedCodeBlock::isNumericCompareFunction): Deleted.
764         * bytecompiler/BytecodeGenerator.cpp:
765         (JSC::BytecodeGenerator::setIsNumericCompareFunction): Deleted.
766         * bytecompiler/BytecodeGenerator.h:
767         * bytecompiler/NodesCodegen.cpp:
768         (JSC::FunctionNode::emitBytecode): We don't do this special casing based
769         on pattern matching anymore. This was mainly an optimization to avoid 
770         the overhead of calling from C++ to JS, which we now avoid by
771         sorting in JS.
772
773         * heap/Heap.cpp:
774         (JSC::Heap::markRoots):
775         (JSC::Heap::pushTempSortVector): Deleted.
776         (JSC::Heap::popTempSortVector): Deleted.
777         (JSC::Heap::visitTempSortVectors): Deleted.
778         * heap/Heap.h: We don't have temp sort vectors anymore because we sort
779         in JavaScript using a normal JavaScript array for our temporary storage.
780
781         * parser/Parser.cpp:
782         (JSC::Parser<LexerType>::parseInner): Allow capturing so we can use
783         helper functions.
784
785         * runtime/ArrayPrototype.cpp:
786         (JSC::isNumericCompareFunction): Deleted.
787         (JSC::attemptFastSort): Deleted.
788         (JSC::performSlowSort): Deleted.
789         (JSC::arrayProtoFuncSort): Deleted.
790
791         * runtime/CommonIdentifiers.h: New strings used by sort.
792
793         * runtime/JSArray.cpp:
794         (JSC::compareNumbersForQSortWithInt32): Deleted.
795         (JSC::compareNumbersForQSortWithDouble): Deleted.
796         (JSC::compareNumbersForQSort): Deleted.
797         (JSC::compareByStringPairForQSort): Deleted.
798         (JSC::JSArray::sortNumericVector): Deleted.
799         (JSC::JSArray::sortNumeric): Deleted.
800         (JSC::ContiguousTypeAccessor::getAsValue): Deleted.
801         (JSC::ContiguousTypeAccessor::setWithValue): Deleted.
802         (JSC::ContiguousTypeAccessor::replaceDataReference): Deleted.
803         (JSC::ContiguousTypeAccessor<ArrayWithDouble>::getAsValue): Deleted.
804         (JSC::ContiguousTypeAccessor<ArrayWithDouble>::setWithValue): Deleted.
805         (JSC::ContiguousTypeAccessor<ArrayWithDouble>::replaceDataReference): Deleted.
806         (JSC::JSArray::sortCompactedVector): Deleted.
807         (JSC::JSArray::sort): Deleted.
808         (JSC::AVLTreeAbstractorForArrayCompare::get_less): Deleted.
809         (JSC::AVLTreeAbstractorForArrayCompare::set_less): Deleted.
810         (JSC::AVLTreeAbstractorForArrayCompare::get_greater): Deleted.
811         (JSC::AVLTreeAbstractorForArrayCompare::set_greater): Deleted.
812         (JSC::AVLTreeAbstractorForArrayCompare::get_balance_factor): Deleted.
813         (JSC::AVLTreeAbstractorForArrayCompare::set_balance_factor): Deleted.
814         (JSC::AVLTreeAbstractorForArrayCompare::compare_key_key): Deleted.
815         (JSC::AVLTreeAbstractorForArrayCompare::compare_key_node): Deleted.
816         (JSC::AVLTreeAbstractorForArrayCompare::compare_node_node): Deleted.
817         (JSC::AVLTreeAbstractorForArrayCompare::null): Deleted.
818         (JSC::JSArray::sortVector): Deleted.
819         (JSC::JSArray::compactForSorting): Deleted.
820         * runtime/JSArray.h:
821
822         * runtime/JSGlobalObject.cpp:
823         (JSC::JSGlobalObject::init):
824         * runtime/ObjectConstructor.cpp:
825         (JSC::ObjectConstructor::finishCreation): Provide some builtins used
826         by sort.
827
828 2015-04-29  Mark Lam  <mark.lam@apple.com>
829
830         Safari WebKit crash when loading Google Spreadsheet.
831         https://bugs.webkit.org/show_bug.cgi?id=144020
832
833         Reviewed by Filip Pizlo.
834
835         The bug is that the object allocation sinking phase did not account for a case
836         where a property of a sunken object is only initialized on one path and not
837         another.  As a result, on the path where the property is not initialized, we'll
838         encounter an Upsilon with a BottomValue (which is not allowed by definition).
839
840         The fix is to use a JSConstant(undefined) as the bottom value instead (of
841         BottomValue).  If the property is uninitialized, it should still be accessible
842         and have the value undefined.
843
844         * dfg/DFGObjectAllocationSinkingPhase.cpp:
845         (JSC::DFG::ObjectAllocationSinkingPhase::promoteSunkenFields):
846         * tests/stress/object-allocation-sinking-with-uninitialized-property-on-one-path.js: Added.
847         (foo):
848         (foo2):
849
850 2015-04-29  Yusuke Suzuki  <utatane.tea@gmail.com>
851
852         REGRESSION (r183373): ASSERT failed in wtf/SHA1.h
853         https://bugs.webkit.org/show_bug.cgi?id=144257
854
855         Reviewed by Darin Adler.
856
857         SHA1 is used to calculate CodeBlockHash.
858         To calculate hash value, we pass the source code UTF-8 CString to SHA1::addBytes.
859         However, the source code can contain null character.
860         So when performing `strlen` on the source code's CString, it returns the incorrect length.
861         In SHA1::addBytes, there's assertion `input.length() == strlen(string)` and it fails.
862
863         In the template-literal-syntax.js, we perform `eval` with the script contains "\0".
864         As the result, `strlen(string)` accidentally shortened by the contained "\0", and assertion fails.
865
866         CString will be changed not to contain a null-character[1]. However, inserting the assertion here
867         is not correct. Because
868
869         1. If CString should not contain a null character, this should be asserted in CString side instead of SHA1::addBytes.
870         2. If CString can contain a null character, this assertion becomes incorrect.
871
872         So this patch just drops the assertion.
873
874         In the current implementation, we once convert the entire source code to the newly allocated
875         UTF-8 string and pass it to the SHA1 processing. However, this is memory consuming.
876         Ideally, we should stream the decoded bytes into the SHA1 processing iteratively.
877         We'll implement it in the separate patch[2].
878
879         [1]: https://bugs.webkit.org/show_bug.cgi?id=144339
880         [2]: https://bugs.webkit.org/show_bug.cgi?id=144263
881
882         * tests/stress/eval-script-contains-null-character.js: Added.
883         (shouldBe):
884         (test):
885         * tests/stress/template-literal-line-terminators.js:
886         * tests/stress/template-literal-syntax.js:
887         * tests/stress/template-literal.js:
888
889 2015-04-29  Filip Pizlo  <fpizlo@apple.com>
890
891         Evict IsEnvironmentRecord from inline type flags
892         https://bugs.webkit.org/show_bug.cgi?id=144398
893
894         Reviewed by Mark Lam and Michael Saboff.
895         
896         In https://bugs.webkit.org/show_bug.cgi?id=144397, we'll need an extra bit in the inline
897         type flags. This change picks the least important inline type flag - IsEnvironmentRecord -
898         and evicts it into the out-of-line type flags. This change has no performance implications
899         because we never even accessed IsEnvironmentRecord via the StructureIDBlob. The only place
900         where we access it at all is in String.prototype.repeat, and there we already load the
901         structure anyway.
902
903         * runtime/JSTypeInfo.h:
904         (JSC::TypeInfo::implementsHasInstance):
905         (JSC::TypeInfo::structureIsImmortal):
906         (JSC::TypeInfo::isEnvironmentRecord):
907
908 2015-04-29  Darin Adler  <darin@apple.com>
909
910         [ES6] Implement Unicode code point escapes
911         https://bugs.webkit.org/show_bug.cgi?id=144377
912
913         Reviewed by Antti Koivisto.
914
915         * parser/Lexer.cpp: Moved the UnicodeHexValue class in here from
916         the header. Made it a non-member class so it doesn't need to be part
917         of a template. Made it use UChar32 instead of int for the value to
918         make it clearer what goes into this class.
919         (JSC::ParsedUnicodeEscapeValue::isIncomplete): Added. Replaces the
920         old type() function.
921         (JSC::Lexer<CharacterType>::parseUnicodeEscape): Renamed from
922         parseFourDigitUnicodeHex and added support for code point escapes.
923         (JSC::isLatin1): Added an overload for UChar32.
924         (JSC::isIdentStart): Changed this to take UChar32; no caller tries
925         to call it with a UChar, so no need to overload for that type for now.
926         (JSC::isNonLatin1IdentPart): Changed argument type to UChar32 for clarity.
927         Also added FIXME about a subtle ES6 change that we might want to make later.
928         (JSC::isIdentPart): Changed this to take UChar32; no caller tries
929         to call it with a UChar, so no need to overload for that type for now.
930         (JSC::isIdentPartIncludingEscapeTemplate): Made this a template so that we
931         don't need to repeat the code twice. Added code to handle code point escapes.
932         (JSC::isIdentPartIncludingEscape): Call the template instead of having the
933         code in line.
934         (JSC::Lexer<CharacterType>::recordUnicodeCodePoint): Added.
935         (JSC::Lexer<CharacterType>::parseIdentifierSlowCase): Made small tweaks and
936         updated to call parseUnicodeEscape instead of parseFourDigitUnicodeHex.
937         (JSC::Lexer<CharacterType>::parseComplexEscape): Call parseUnicodeEscape
938         instead of parseFourDigitUnicodeHex. Move the code to handle "\u" before
939         the code that handles the escapes, since the code point escape code now
940         consumes characters while parsing rather than peeking ahead. Test case
941         covers this: Symptom would be that "\u{" would evaluate to "u" instead of
942         giving a syntax error.
943
944         * parser/Lexer.h: Updated for above changes.
945
946         * runtime/StringConstructor.cpp:
947         (JSC::stringFromCodePoint): Use ICU's UCHAR_MAX_VALUE instead of writing
948         out 0x10FFFF; clearer this way.
949
950 2015-04-29  Martin Robinson  <mrobinson@igalia.com>
951
952         [CMake] [GTK] Organize and clean up unused CMake variables
953         https://bugs.webkit.org/show_bug.cgi?id=144364
954
955         Reviewed by Gyuyoung Kim.
956
957         * PlatformGTK.cmake: Add variables specific to this project.
958
959 2015-04-28  Filip Pizlo  <fpizlo@apple.com>
960
961         TypeOf should return SpecStringIdent and the DFG should know this
962         https://bugs.webkit.org/show_bug.cgi?id=144376
963
964         Reviewed by Andreas Kling.
965         
966         Make TypeOf return atomic strings. That's a simple change in SmallStrings.
967         
968         Make the DFG know this and use it for optimization. This makes Switch(TypeOf) a bit less
969         bad.
970
971         * dfg/DFGAbstractInterpreterInlines.h:
972         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
973         * dfg/DFGAbstractValue.cpp:
974         (JSC::DFG::AbstractValue::setType):
975         * dfg/DFGAbstractValue.h:
976         (JSC::DFG::AbstractValue::setType):
977         * dfg/DFGInPlaceAbstractState.cpp:
978         (JSC::DFG::InPlaceAbstractState::initialize):
979         * dfg/DFGPredictionPropagationPhase.cpp:
980         (JSC::DFG::PredictionPropagationPhase::propagate):
981         * runtime/SmallStrings.cpp:
982         (JSC::SmallStrings::initialize):
983         * tests/stress/switch-typeof-indirect.js: Added.
984         (bar):
985         (foo):
986         (test):
987         * tests/stress/switch-typeof-slightly-indirect.js: Added.
988         (foo):
989         (test):
990         * tests/stress/switch-typeof.js: Added.
991         (foo):
992         (test):
993
994 2015-04-29  Joseph Pecoraro  <pecoraro@apple.com>
995
996         REGRESSION(181868): Windows Live SkyDrive cannot open an excel file
997         https://bugs.webkit.org/show_bug.cgi?id=144373
998
999         Reviewed by Darin Adler.
1000
1001         Revert r181868 as it caused a failure on live.com. We can try
1002         re-enabling this exception after we make idl attributes configurable,
1003         which may have prevented this particular failure.
1004
1005         * runtime/ObjectPrototype.cpp:
1006         (JSC::objectProtoFuncDefineGetter):
1007         (JSC::objectProtoFuncDefineSetter):
1008
1009 2015-04-28  Joseph Pecoraro  <pecoraro@apple.com>
1010
1011         Deadlock on applications using JSContext on non-main thread
1012         https://bugs.webkit.org/show_bug.cgi?id=144370
1013
1014         Reviewed by Timothy Hatcher.
1015
1016         * inspector/remote/RemoteInspector.mm:
1017         (Inspector::RemoteInspector::singleton):
1018         Prevent a possible deadlock by assuming we can synchronously
1019         run something on the main queue at this time.
1020
1021 2015-04-28  Filip Pizlo  <fpizlo@apple.com>
1022
1023         FTL should fully support Switch (it currently lacks the SwitchString variant)
1024         https://bugs.webkit.org/show_bug.cgi?id=144348
1025
1026         Reviewed by Benjamin Poulain.
1027         
1028         This adds SwitchString support to the FTL. This is already tested by switch microbenchmarks
1029         in LayoutTests/js/regress.
1030
1031         * dfg/DFGCommon.cpp:
1032         (JSC::DFG::stringLessThan):
1033         * dfg/DFGCommon.h:
1034         * dfg/DFGOperations.cpp:
1035         * dfg/DFGOperations.h:
1036         * dfg/DFGSpeculativeJIT.cpp:
1037         (JSC::DFG::SpeculativeJIT::StringSwitchCase::operator<): Deleted.
1038         * dfg/DFGSpeculativeJIT.h:
1039         (JSC::DFG::SpeculativeJIT::StringSwitchCase::operator<):
1040         * ftl/FTLCapabilities.cpp:
1041         (JSC::FTL::canCompile):
1042         * ftl/FTLIntrinsicRepository.h:
1043         * ftl/FTLLowerDFGToLLVM.cpp:
1044         (JSC::FTL::LowerDFGToLLVM::compileSwitch):
1045         (JSC::FTL::LowerDFGToLLVM::switchString):
1046         (JSC::FTL::LowerDFGToLLVM::StringSwitchCase::StringSwitchCase):
1047         (JSC::FTL::LowerDFGToLLVM::StringSwitchCase::operator<):
1048         (JSC::FTL::LowerDFGToLLVM::CharacterCase::CharacterCase):
1049         (JSC::FTL::LowerDFGToLLVM::CharacterCase::operator<):
1050         (JSC::FTL::LowerDFGToLLVM::switchStringRecurse):
1051         (JSC::FTL::LowerDFGToLLVM::switchStringSlow):
1052         (JSC::FTL::LowerDFGToLLVM::appendOSRExit):
1053         * ftl/FTLOutput.cpp:
1054         (JSC::FTL::Output::check):
1055         * ftl/FTLOutput.h:
1056         * ftl/FTLWeight.h:
1057         (JSC::FTL::Weight::inverse):
1058         * jit/JITOperations.h:
1059
1060 2015-04-28  Michael Catanzaro  <mcatanzaro@igalia.com>
1061
1062         Fully replace ENABLE_LLINT_C_LOOP with ENABLE_JIT
1063         https://bugs.webkit.org/show_bug.cgi?id=144304
1064
1065         Reviewed by Geoffrey Garen.
1066
1067         * Configurations/FeatureDefines.xcconfig: Define ENABLE_JIT, enabled by default, instead of
1068         ENABLE_LLINT_C_LOOP, disabled by default.
1069         * llint/LLIntSlowPaths.cpp:
1070         (JSC::LLInt::LLINT_SLOW_PATH_DECL): Check ENABLE_JIT instead of ENABLE_LLINT_C_LOOP.
1071
1072 2015-04-28  Commit Queue  <commit-queue@webkit.org>
1073
1074         Unreviewed, rolling out r183514.
1075         https://bugs.webkit.org/show_bug.cgi?id=144359
1076
1077         It broke cloop test bots (Requested by mcatanzaro on #webkit).
1078
1079         Reverted changeset:
1080
1081         "Fully replace ENABLE_LLINT_C_LOOP with ENABLE_JIT"
1082         https://bugs.webkit.org/show_bug.cgi?id=144304
1083         http://trac.webkit.org/changeset/183514
1084
1085 2015-04-28  Michael Catanzaro  <mcatanzaro@igalia.com>
1086
1087         Fully replace ENABLE_LLINT_C_LOOP with ENABLE_JIT
1088         https://bugs.webkit.org/show_bug.cgi?id=144304
1089
1090         Reviewed by Geoffrey Garen.
1091
1092         * Configurations/FeatureDefines.xcconfig: Define ENABLE_JIT, enabled by default, instead of
1093         ENABLE_LLINT_C_LOOP, disabled by default.
1094         * llint/LLIntSlowPaths.cpp:
1095         (JSC::LLInt::LLINT_SLOW_PATH_DECL): Check ENABLE_JIT instead of ENABLE_LLINT_C_LOOP.
1096
1097 2015-04-28  Joseph Pecoraro  <pecoraro@apple.com>
1098
1099         Fix common typo "targetting" => "targeting"
1100         https://bugs.webkit.org/show_bug.cgi?id=144349
1101
1102         Reviewed by Daniel Bates.
1103
1104         * bytecode/ExecutionCounter.h:
1105
1106 2015-04-28  Yusuke Suzuki  <utatane.tea@gmail.com>
1107
1108         Update the features.json for WeakSet, WeakMap, Template literals, Tagged templates
1109         https://bugs.webkit.org/show_bug.cgi?id=144328
1110
1111         Reviewed by Andreas Kling.
1112
1113         Update the status of ES6 features.
1114
1115         * features.json:
1116
1117 2015-04-28  Filip Pizlo  <fpizlo@apple.com>
1118
1119         DFG should not use or preserve Phantoms during transformations
1120         https://bugs.webkit.org/show_bug.cgi?id=143736
1121
1122         Reviewed by Geoffrey Garen.
1123         
1124         Since http://trac.webkit.org/changeset/183207 and http://trac.webkit.org/changeset/183406, it is
1125         no longer necessary to preserve Phantoms during transformations. They are still useful just
1126         before FixupPhase to support backwards propagation analyses. They are still inserted late in the
1127         game in the DFG backend. But transformations don't need to worry about them. Inside a basic
1128         block, we can be sure that so long as the IR pinpoints the place where the value becomes
1129         available in a bytecode register (using MovHint) and so long as there is a SetLocal anytime some
1130         other block would need the value (either for OSR or for DFG execution), then we don't need any
1131         liveness markers.
1132         
1133         So, this removes any places where we inserted Phantoms just for liveness during transformation
1134         and it replaces convertToPhantom() with remove(), which just converts the node to a Check. A
1135         Check node only keeps its children so long as those children have checks.
1136         
1137         The fact that we no longer convertToPhantom() means that we have to be more careful when
1138         constant-folding GetLocal. Previously we would convertToPhantom() and use the fact that
1139         Phantom(Phi) was a valid construct. It's not valid anymore. So, when constant folding encounters
1140         a GetLocal it needs to insert a PhantomLocal directly. This allows us to simplify
1141         Graph::convertToConstant() a bit. Luckily, none of the other users of this method would see
1142         GetLocals.
1143         
1144         The only Phantom-like cruft left over after this patch is:
1145         
1146         - Phantoms before FixupPhase. I kind of like these. It means that before FixupPhase, we can do
1147           backwards analyses and rely on the fact that the users of a node in DFG IR are a superset of
1148           the users of the original local's live range in bytecode. This is essential for supporting our
1149           BackwardsPropagationPhase, which is an important optimization for things like asm.js.
1150         
1151         - PhantomLocals and GetLocals being NodeMustGenerate. See discussion in
1152           https://bugs.webkit.org/show_bug.cgi?id=144086. It appears that this is not as evil as the
1153           alternatives. The best long-term plan is to simply ditch the ThreadedCPS IR entirely and have
1154           the DFG use SSA. For now, so long as any new DFG optimizations we add are block-local and
1155           treat GetLocal/SetLocal conservatively, this should all be sound.
1156         
1157         This change should be perf-neutral although it does reduce the total work that the compiler
1158         does.
1159
1160         * CMakeLists.txt:
1161         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
1162         * JavaScriptCore.xcodeproj/project.pbxproj:
1163         * dfg/DFGAdjacencyList.h:
1164         (JSC::DFG::AdjacencyList::justChecks):
1165         * dfg/DFGArgumentsEliminationPhase.cpp:
1166         * dfg/DFGBasicBlock.cpp:
1167         (JSC::DFG::BasicBlock::replaceTerminal):
1168         * dfg/DFGBasicBlock.h:
1169         (JSC::DFG::BasicBlock::findTerminal):
1170         * dfg/DFGCFGSimplificationPhase.cpp:
1171         (JSC::DFG::CFGSimplificationPhase::keepOperandAlive):
1172         (JSC::DFG::CFGSimplificationPhase::mergeBlocks):
1173         * dfg/DFGCPSRethreadingPhase.cpp:
1174         (JSC::DFG::CPSRethreadingPhase::CPSRethreadingPhase):
1175         (JSC::DFG::CPSRethreadingPhase::clearVariables):
1176         (JSC::DFG::CPSRethreadingPhase::canonicalizeFlushOrPhantomLocalFor):
1177         (JSC::DFG::CPSRethreadingPhase::canonicalizeLocalsInBlock):
1178         * dfg/DFGCSEPhase.cpp:
1179         * dfg/DFGCleanUpPhase.cpp: Copied from Source/JavaScriptCore/dfg/DFGPhantomRemovalPhase.cpp.
1180         (JSC::DFG::CleanUpPhase::CleanUpPhase):
1181         (JSC::DFG::CleanUpPhase::run):
1182         (JSC::DFG::performCleanUp):
1183         (JSC::DFG::PhantomRemovalPhase::PhantomRemovalPhase): Deleted.
1184         (JSC::DFG::PhantomRemovalPhase::run): Deleted.
1185         (JSC::DFG::performPhantomRemoval): Deleted.
1186         * dfg/DFGCleanUpPhase.h: Copied from Source/JavaScriptCore/dfg/DFGPhantomRemovalPhase.h.
1187         * dfg/DFGConstantFoldingPhase.cpp:
1188         (JSC::DFG::ConstantFoldingPhase::foldConstants):
1189         (JSC::DFG::ConstantFoldingPhase::addBaseCheck):
1190         (JSC::DFG::ConstantFoldingPhase::fixUpsilons):
1191         * dfg/DFGDCEPhase.cpp:
1192         (JSC::DFG::DCEPhase::run):
1193         (JSC::DFG::DCEPhase::fixupBlock):
1194         (JSC::DFG::DCEPhase::cleanVariables):
1195         * dfg/DFGFixupPhase.cpp:
1196         (JSC::DFG::FixupPhase::fixupBlock):
1197         (JSC::DFG::FixupPhase::fixupNode):
1198         (JSC::DFG::FixupPhase::convertStringAddUse):
1199         (JSC::DFG::FixupPhase::attemptToMakeFastStringAdd):
1200         (JSC::DFG::FixupPhase::checkArray):
1201         (JSC::DFG::FixupPhase::fixIntConvertingEdge):
1202         (JSC::DFG::FixupPhase::fixIntOrBooleanEdge):
1203         (JSC::DFG::FixupPhase::fixDoubleOrBooleanEdge):
1204         (JSC::DFG::FixupPhase::injectTypeConversionsInBlock):
1205         (JSC::DFG::FixupPhase::tryToRelaxRepresentation):
1206         (JSC::DFG::FixupPhase::injectTypeConversionsForEdge):
1207         (JSC::DFG::FixupPhase::addRequiredPhantom): Deleted.
1208         (JSC::DFG::FixupPhase::addPhantomsIfNecessary): Deleted.
1209         * dfg/DFGGraph.cpp:
1210         (JSC::DFG::Graph::convertToConstant):
1211         (JSC::DFG::Graph::mergeRelevantToOSR): Deleted.
1212         * dfg/DFGGraph.h:
1213         * dfg/DFGInsertionSet.h:
1214         (JSC::DFG::InsertionSet::insertCheck):
1215         * dfg/DFGIntegerCheckCombiningPhase.cpp:
1216         (JSC::DFG::IntegerCheckCombiningPhase::handleBlock):
1217         * dfg/DFGLICMPhase.cpp:
1218         (JSC::DFG::LICMPhase::attemptHoist):
1219         * dfg/DFGNode.cpp:
1220         (JSC::DFG::Node::remove):
1221         * dfg/DFGNode.h:
1222         (JSC::DFG::Node::replaceWith):
1223         (JSC::DFG::Node::convertToPhantom): Deleted.
1224         (JSC::DFG::Node::convertToCheck): Deleted.
1225         (JSC::DFG::Node::willHaveCodeGenOrOSR): Deleted.
1226         * dfg/DFGNodeFlags.h:
1227         * dfg/DFGNodeType.h:
1228         * dfg/DFGObjectAllocationSinkingPhase.cpp:
1229         (JSC::DFG::ObjectAllocationSinkingPhase::lowerNonReadingOperationsOnPhantomAllocations):
1230         (JSC::DFG::ObjectAllocationSinkingPhase::handleNode):
1231         * dfg/DFGPhantomCanonicalizationPhase.cpp: Removed.
1232         * dfg/DFGPhantomCanonicalizationPhase.h: Removed.
1233         * dfg/DFGPhantomRemovalPhase.cpp: Removed.
1234         * dfg/DFGPhantomRemovalPhase.h: Removed.
1235         * dfg/DFGPlan.cpp:
1236         (JSC::DFG::Plan::compileInThreadImpl):
1237         * dfg/DFGPutStackSinkingPhase.cpp:
1238         * dfg/DFGResurrectionForValidationPhase.cpp: Removed.
1239         * dfg/DFGResurrectionForValidationPhase.h: Removed.
1240         * dfg/DFGSSAConversionPhase.cpp:
1241         (JSC::DFG::SSAConversionPhase::run):
1242         * dfg/DFGSpeculativeJIT64.cpp:
1243         (JSC::DFG::SpeculativeJIT::fillSpeculateDouble):
1244         * dfg/DFGStoreBarrierElisionPhase.cpp:
1245         (JSC::DFG::StoreBarrierElisionPhase::elideBarrier):
1246         * dfg/DFGStrengthReductionPhase.cpp:
1247         (JSC::DFG::StrengthReductionPhase::handleNode):
1248         (JSC::DFG::StrengthReductionPhase::convertToIdentityOverChild):
1249         * dfg/DFGValidate.cpp:
1250         (JSC::DFG::Validate::validate):
1251         (JSC::DFG::Validate::validateCPS):
1252         (JSC::DFG::Validate::validateSSA):
1253         * dfg/DFGVarargsForwardingPhase.cpp:
1254         * ftl/FTLLink.cpp:
1255         (JSC::FTL::link):
1256         * ftl/FTLLowerDFGToLLVM.cpp:
1257         (JSC::FTL::LowerDFGToLLVM::compileNode):
1258         (JSC::FTL::LowerDFGToLLVM::compileNoOp):
1259         (JSC::FTL::LowerDFGToLLVM::compilePhantom): Deleted.
1260
1261 2015-04-28  Andreas Kling  <akling@apple.com>
1262
1263         DFG+FTL should generate efficient code for branching on a string's boolean value.
1264         <https://webkit.org/b/144317>
1265
1266         Reviewed by Geoff Garen & Filip Pizlo
1267
1268         Teach Branch nodes about StringUse and have them generate an efficient zero-length string check
1269         instead of dropping out to C++ whenever we branch on a string.
1270
1271         The FTL JIT already handled Branch nodes with StringUse through its use of boolify(), so only
1272         the DFG JIT gets some new codegen logic in this patch.
1273
1274         Test: js/regress/branch-on-string-as-boolean.js (~4.5x speedup)
1275
1276         * dfg/DFGFixupPhase.cpp:
1277         (JSC::DFG::FixupPhase::fixupNode):
1278         * dfg/DFGSpeculativeJIT.cpp:
1279         (JSC::DFG::SpeculativeJIT::emitStringBranch):
1280         * dfg/DFGSpeculativeJIT.h:
1281         * dfg/DFGSpeculativeJIT32_64.cpp:
1282         (JSC::DFG::SpeculativeJIT::emitBranch):
1283         * dfg/DFGSpeculativeJIT64.cpp:
1284         (JSC::DFG::SpeculativeJIT::emitBranch):
1285
1286 2015-04-28  Filip Pizlo  <fpizlo@apple.com>
1287
1288         VarargsForwardingPhase should only consider MovHints that have the candidate as a child
1289         https://bugs.webkit.org/show_bug.cgi?id=144340
1290
1291         Reviewed by Michael Saboff and Mark Lam.
1292         
1293         Since we were considering all MovHints, we'd assume that the CreateDirectArguments or
1294         CreateClosedArguments node was live so long as any MovHinted bytecode variable was alive.
1295         Basically, we'd keep it alive until the end of the block. This maximized the chances of
1296         there being an interfering operation, which would prevent elimination.
1297         
1298         The fix is to only consider MovHints that have the arguments candidate as a child. We only
1299         care to track the liveness of those bytecode locals that would need an arguments object
1300         recovery on OSR exit.
1301         
1302         This is a speed-up on V8Spider/raytrace and Octane/raytrace because it undoes the regression
1303         introduced in http://trac.webkit.org/changeset/183406.
1304
1305         * dfg/DFGVarargsForwardingPhase.cpp:
1306
1307 2015-04-28  Csaba Osztrogon√°c  <ossy@webkit.org>
1308
1309         Remove WinCE cruft from cmake build system
1310         https://bugs.webkit.org/show_bug.cgi?id=144325
1311
1312         Reviewed by Gyuyoung Kim.
1313
1314         * CMakeLists.txt:
1315         * create_jit_stubs: Removed.
1316
1317 2015-04-27  Andreas Kling  <akling@apple.com>
1318
1319         RegExp matches arrays should use contiguous indexing.
1320         <https://webkit.org/b/144286>
1321
1322         Reviewed by Geoffrey Garen.
1323
1324         We had a custom Structure being used for RegExp matches arrays that would
1325         put the arrays into SlowPutArrayStorageShape mode. This was just left
1326         from when matches arrays were custom, lazily initialized objects.
1327
1328         This change removes that Structure and switches the matches arrays to
1329         using the default ContiguousShape Structure. This allows the FTL JIT
1330         to compile the inner loop of the Octane/regexp benchmark.
1331
1332         Also made a version of initializeIndex() [inline] that takes the indexing
1333         type in an argument, allowing createRegExpMatchesArray() to initialize
1334         the entire array without branching on the indexing type for each entry.
1335
1336         ~3% progression on Octane/regexp.
1337
1338         * runtime/JSGlobalObject.cpp:
1339         (JSC::JSGlobalObject::init):
1340         (JSC::JSGlobalObject::visitChildren):
1341         * runtime/JSGlobalObject.h:
1342         (JSC::JSGlobalObject::mapStructure):
1343         (JSC::JSGlobalObject::regExpMatchesArrayStructure): Deleted.
1344         * runtime/JSObject.h:
1345         (JSC::JSObject::initializeIndex):
1346         * runtime/RegExpMatchesArray.cpp:
1347         (JSC::createRegExpMatchesArray):
1348
1349 2015-04-27  Filip Pizlo  <fpizlo@apple.com>
1350
1351         FTL failed to initialize arguments.callee on the slow path as well as the fast path
1352         https://bugs.webkit.org/show_bug.cgi?id=144293
1353
1354         Reviewed by Mark Lam.
1355         
1356         The slow path doesn't fully initialize DirectArguments - it leaves callee blank. So, we need
1357         to initialize the callee on the common path after the fast and slow path.
1358
1359         * ftl/FTLLowerDFGToLLVM.cpp:
1360         (JSC::FTL::LowerDFGToLLVM::compileCreateDirectArguments):
1361         * tests/stress/arguments-callee-uninitialized.js: Added.
1362         (foo):
1363
1364 2015-04-27  Benjamin Poulain  <bpoulain@apple.com>
1365
1366         [JSC] Add support for typed arrays to the Array profiling
1367         https://bugs.webkit.org/show_bug.cgi?id=143913
1368
1369         Reviewed by Filip Pizlo.
1370
1371         This patch adds ArrayModes for every typed arrays. Having that information
1372         let us generate better GetByVal and PutByVal when the type speculation
1373         are not good enough.
1374
1375         A typical case where this is useful is any basic block for which the type
1376         of the object is always more restrictive than the speculation (for example, 
1377         a basic block gated by a branch only taken for on type).
1378
1379         * bytecode/ArrayProfile.cpp:
1380         (JSC::dumpArrayModes):
1381         * bytecode/ArrayProfile.h:
1382         (JSC::arrayModeFromStructure):
1383         * dfg/DFGArrayMode.cpp:
1384         (JSC::DFG::ArrayMode::fromObserved):
1385         (JSC::DFG::ArrayMode::refine):
1386         Maintain the refine() semantic. We do not support OutOfBounds access
1387         for GetByVal on typed array.
1388
1389         * runtime/IndexingType.h:
1390         * tests/stress/typed-array-get-by-val-profiling.js: Added.
1391         (testArray.testCode):
1392         (testArray):
1393         * tests/stress/typed-array-put-by-val-profiling.js: Added.
1394         (testArray.testCode):
1395         (testArray):
1396
1397 2015-04-27  Filip Pizlo  <fpizlo@apple.com>
1398
1399         Unreviewed, roll out r183438 "RegExp matches arrays should use contiguous indexing". It
1400         causes many debug test failures.
1401
1402         * runtime/JSGlobalObject.cpp:
1403         (JSC::JSGlobalObject::init):
1404         (JSC::JSGlobalObject::visitChildren):
1405         * runtime/JSGlobalObject.h:
1406         (JSC::JSGlobalObject::regExpMatchesArrayStructure):
1407         * runtime/JSObject.h:
1408         (JSC::JSObject::initializeIndex):
1409         * runtime/RegExpMatchesArray.cpp:
1410         (JSC::createRegExpMatchesArray):
1411
1412 2015-04-27  Andreas Kling  <akling@apple.com>
1413
1414         RegExp matches arrays should use contiguous indexing.
1415         <https://webkit.org/b/144286>
1416
1417         Reviewed by Geoffrey Garen.
1418
1419         We had a custom Structure being used for RegExp matches arrays that would
1420         put the arrays into SlowPutArrayStorageShape mode. This was just left
1421         from when matches arrays were custom, lazily initialized objects.
1422
1423         This change removes that Structure and switches the matches arrays to
1424         using the default ContiguousShape Structure. This allows the FTL JIT
1425         to compile the inner loop of the Octane/regexp benchmark.
1426
1427         Also made a version of initializeIndex() [inline] that takes the indexing
1428         type in an argument, allowing createRegExpMatchesArray() to initialize
1429         the entire array without branching on the indexing type for each entry.
1430
1431         ~3% progression on Octane/regexp.
1432
1433         * runtime/JSGlobalObject.cpp:
1434         (JSC::JSGlobalObject::init):
1435         (JSC::JSGlobalObject::visitChildren):
1436         * runtime/JSGlobalObject.h:
1437         (JSC::JSGlobalObject::mapStructure):
1438         (JSC::JSGlobalObject::regExpMatchesArrayStructure): Deleted.
1439         * runtime/JSObject.h:
1440         (JSC::JSObject::initializeIndex):
1441         * runtime/RegExpMatchesArray.cpp:
1442         (JSC::createRegExpMatchesArray):
1443
1444 2015-04-27  Ryosuke Niwa  <rniwa@webkit.org>
1445
1446         REGRESSION (r183373): ASSERT failed in wtf/SHA1.h
1447         https://bugs.webkit.org/show_bug.cgi?id=144257
1448
1449         Temporarily disable skip these tests.
1450
1451         * tests/stress/template-literal-line-terminators.js:
1452         * tests/stress/template-literal-syntax.js:
1453         * tests/stress/template-literal.js:
1454
1455 2015-04-27  Basile Clement  <basile_clement@apple.com>
1456
1457         Function allocations shouldn't sink through Put operations
1458         https://bugs.webkit.org/show_bug.cgi?id=144176
1459
1460         Reviewed by Filip Pizlo.
1461
1462         By design, we don't support function allocation sinking through any
1463         related operation ; however object allocation can sink through PutByOffset et
1464         al.
1465
1466         Currently, the checks to prevent function allocation to sink through
1467         these are misguided and do not prevent anything ; function allocation sinking
1468         through these operations is prevented as a side effect of requiring an
1469         AllocatePropertyStorage through which the function allocation is seen as
1470         escaping.
1471
1472         This changes it so that ObjectAllocationSinkingPhase::handleNode()
1473         checks properly that only object allocations sink through related write
1474         operations.
1475
1476         * dfg/DFGObjectAllocationSinkingPhase.cpp:
1477         (JSC::DFG::ObjectAllocationSinkingPhase::lowerNonReadingOperationsOnPhantomAllocations):
1478         (JSC::DFG::ObjectAllocationSinkingPhase::handleNode):
1479
1480 2015-04-25  Filip Pizlo  <fpizlo@apple.com>
1481
1482         VarargsForwardingPhase should use bytecode liveness in addition to other uses to determine the last point that a candidate is used
1483         https://bugs.webkit.org/show_bug.cgi?id=143843
1484
1485         Reviewed by Geoffrey Garen.
1486         
1487         It will soon come to pass that Phantom isn't available at the time that
1488         VarargsForwardingPhase runs. So, it needs to use some other mechanism for discovering when
1489         a value dies for OSR.
1490         
1491         This is simplified by two things:
1492         
1493         1) The bytecode kill analysis is now reusable. This patch makes it even more reusable than
1494            before by polishing the API.
1495         
1496         2) This phase already operates on one node at a time and allows itself to do a full search
1497            of the enclosing basic block for that node. This is fine because CreateDirectArguments
1498            and friends is a rarely occurring node. The fact that it operates on one node at a time
1499            makes it even easier to reason about OSR liveness - we just track the list of locals in
1500            which it is live.
1501         
1502         This change has no effect right now but it is a necessary prerequisite to implementing
1503         https://bugs.webkit.org/show_bug.cgi?id=143736.
1504
1505         * dfg/DFGBasicBlock.h:
1506         (JSC::DFG::BasicBlock::tryAt):
1507         * dfg/DFGForAllKills.h:
1508         (JSC::DFG::forAllKilledOperands):
1509         * dfg/DFGPhantomInsertionPhase.cpp:
1510         * dfg/DFGVarargsForwardingPhase.cpp:
1511
1512 2015-04-27  Jordan Harband  <ljharb@gmail.com>
1513
1514         Map#entries and Map#keys error for non-Maps is swapped
1515         https://bugs.webkit.org/show_bug.cgi?id=144253
1516
1517         Reviewed by Simon Fraser.
1518
1519         Correcting error messages on Set/Map methods when called on
1520         incompatible objects.
1521
1522         * runtime/MapPrototype.cpp:
1523         (JSC::mapProtoFuncEntries):
1524         (JSC::mapProtoFuncKeys):
1525         * runtime/SetPrototype.cpp:
1526         (JSC::setProtoFuncEntries):
1527
1528 2015-04-24  Filip Pizlo  <fpizlo@apple.com>
1529
1530         Rationalize DFG DCE handling of nodes that perform checks that propagate through AI
1531         https://bugs.webkit.org/show_bug.cgi?id=144186
1532
1533         Reviewed by Geoffrey Garen.
1534         
1535         If I do ArithAdd(Int32Use, Int32Use, CheckOverflow) then AI will prove that this returns
1536         Int32. We may later perform code simplifications based on the proof that this is Int32, and
1537         we may kill all DFG users of this ArithAdd. Then we may prove that there is no exit site at
1538         which the ArithAdd is live. This seems like it is sufficient to then kill the ArithAdd,
1539         except that we still need the overflow check!
1540
1541         Previously we mishandled this:
1542
1543         - In places where we want the overflow check we need to use MustGenerate(@ArithAdd) as a hack
1544           to keep it alive. That's dirty and it's just indicative of a deeper issue.
1545
1546         - Our MovHint removal doesn't do Phantom canonicalization which essentially makes it
1547           powerless. This was sort of hiding the bug.
1548
1549         - Nodes that have checks that AI leverages should always be NodeMustGenerate. You can't kill
1550           something that you are relying on for subsequent simplifications.
1551         
1552         This fixes MovHint removal to also canonicalize Phantoms. This also adds ModeMustGenerate to
1553         nodes that may perform checks that are used by AI to guarantee the result type. As a result,
1554         we no longer need the weird MustGenerate node.
1555
1556         * dfg/DFGAbstractInterpreterInlines.h:
1557         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
1558         * dfg/DFGArgumentsEliminationPhase.cpp:
1559         * dfg/DFGClobberize.h:
1560         (JSC::DFG::clobberize):
1561         * dfg/DFGDCEPhase.cpp:
1562         (JSC::DFG::DCEPhase::run):
1563         * dfg/DFGDoesGC.cpp:
1564         (JSC::DFG::doesGC):
1565         * dfg/DFGFixupPhase.cpp:
1566         (JSC::DFG::FixupPhase::fixupNode):
1567         (JSC::DFG::FixupPhase::tryToRelaxRepresentation):
1568         * dfg/DFGIntegerCheckCombiningPhase.cpp:
1569         (JSC::DFG::IntegerCheckCombiningPhase::handleBlock):
1570         (JSC::DFG::IntegerCheckCombiningPhase::insertMustAdd): Deleted.
1571         * dfg/DFGMayExit.cpp:
1572         (JSC::DFG::mayExit):
1573         * dfg/DFGNode.h:
1574         (JSC::DFG::Node::willHaveCodeGenOrOSR):
1575         * dfg/DFGNodeType.h:
1576         * dfg/DFGObjectAllocationSinkingPhase.cpp:
1577         (JSC::DFG::ObjectAllocationSinkingPhase::handleNode):
1578         * dfg/DFGPhantomCanonicalizationPhase.cpp:
1579         (JSC::DFG::PhantomCanonicalizationPhase::run):
1580         * dfg/DFGPhantomRemovalPhase.cpp:
1581         (JSC::DFG::PhantomRemovalPhase::run):
1582         * dfg/DFGPlan.cpp:
1583         (JSC::DFG::Plan::compileInThreadImpl):
1584         * dfg/DFGPredictionPropagationPhase.cpp:
1585         (JSC::DFG::PredictionPropagationPhase::propagate):
1586         * dfg/DFGSafeToExecute.h:
1587         (JSC::DFG::safeToExecute):
1588         * dfg/DFGSpeculativeJIT32_64.cpp:
1589         (JSC::DFG::SpeculativeJIT::compile):
1590         * dfg/DFGSpeculativeJIT64.cpp:
1591         (JSC::DFG::SpeculativeJIT::compile):
1592         * dfg/DFGTypeCheckHoistingPhase.cpp:
1593         (JSC::DFG::TypeCheckHoistingPhase::identifyRedundantStructureChecks):
1594         (JSC::DFG::TypeCheckHoistingPhase::identifyRedundantArrayChecks):
1595         * dfg/DFGVarargsForwardingPhase.cpp:
1596         * ftl/FTLCapabilities.cpp:
1597         (JSC::FTL::canCompile):
1598         * ftl/FTLLowerDFGToLLVM.cpp:
1599         (JSC::FTL::LowerDFGToLLVM::compileNode):
1600         * tests/stress/fold-based-on-int32-proof-mul-branch.js: Added.
1601         (foo):
1602         * tests/stress/fold-based-on-int32-proof-mul.js: Added.
1603         (foo):
1604         * tests/stress/fold-based-on-int32-proof-or-zero.js: Added.
1605         (foo):
1606         * tests/stress/fold-based-on-int32-proof.js: Added.
1607         (foo):
1608
1609 2015-04-26  Ryosuke Niwa  <rniwa@webkit.org>
1610
1611         Class body ending with a semicolon throws a SyntaxError
1612         https://bugs.webkit.org/show_bug.cgi?id=144244
1613
1614         Reviewed by Darin Adler.
1615
1616         The bug was caused by parseClass's inner loop for method definitions not moving onto the next iteration
1617         it encounters a semicolon. As a result, we always expected a method to appear after a semicolon. Fixed
1618         it by continue'ing when it encounters a semicolon.
1619
1620         * parser/Parser.cpp:
1621         (JSC::Parser<LexerType>::parseClass):
1622
1623 2015-04-26  Ryosuke Niwa  <rniwa@webkit.org>
1624
1625         Getter or setter method named "prototype" or "constrcutor" should throw SyntaxError
1626         https://bugs.webkit.org/show_bug.cgi?id=144243
1627
1628         Reviewed by Darin Adler.
1629
1630         Fixed the bug by adding explicit checks in parseGetterSetter when we're parsing class methods.
1631
1632         * parser/Parser.cpp:
1633         (JSC::Parser<LexerType>::parseGetterSetter):
1634
1635 2015-04-26  Jordan Harband  <ljharb@gmail.com>
1636
1637         Map#forEach does not pass "map" argument to callback.
1638         https://bugs.webkit.org/show_bug.cgi?id=144187
1639
1640         Reviewed by Darin Adler.
1641
1642         Per https://people.mozilla.org/~jorendorff/es6-draft.html#sec-map.prototype.foreach
1643         step 7.a.i., the callback should be called with three arguments.
1644
1645         * runtime/MapPrototype.cpp:
1646         (JSC::mapProtoFuncForEach):
1647
1648 2015-04-26  Yusuke Suzuki  <utatane.tea@gmail.com>
1649
1650         [ES6] Implement ES6 template literals
1651         https://bugs.webkit.org/show_bug.cgi?id=142691
1652
1653         Reviewed by Darin Adler.
1654
1655         This patch implements TemplateLiteral.
1656         Since TaggedTemplate requires some global states and
1657         primitive operations like GetTemplateObject,
1658         we separate the patch. It will be implemented in a subsequent patch.
1659
1660         Template Literal Syntax is guarded by ENABLE_ES6_TEMPLATE_LITERAL_SYNTAX compile time flag.
1661         By disabling it, we can disable Template Literal support.
1662
1663         To implement template literals, in this patch,
1664         we newly introduces bytecode op_to_string.
1665         In template literals, we alternately evaluate the expression and
1666         perform ToString onto the result of evaluation.
1667         For example,
1668
1669         `${f1()} ${f2()}`
1670
1671         In this template literal, execution order is the following,
1672         1. calling f1()
1673         2. ToString(the result of f1())
1674         3. calling f2()
1675         4. ToString(the result of f2())
1676
1677         op_strcat also performs ToString. However, performing ToString
1678         onto expressions are batched in op_strcat, it's not the same to the
1679         template literal spec. In the above example,
1680         ToString(f1()) should be called before calling f2().
1681
1682         * Configurations/FeatureDefines.xcconfig:
1683         * bytecode/BytecodeList.json:
1684         * bytecode/BytecodeUseDef.h:
1685         (JSC::computeUsesForBytecodeOffset):
1686         (JSC::computeDefsForBytecodeOffset):
1687         * bytecode/CodeBlock.cpp:
1688         (JSC::CodeBlock::dumpBytecode):
1689         * bytecompiler/BytecodeGenerator.h:
1690         (JSC::BytecodeGenerator::emitToString):
1691         (JSC::BytecodeGenerator::emitToNumber): Deleted.
1692         * bytecompiler/NodesCodegen.cpp:
1693         (JSC::TemplateStringNode::emitBytecode):
1694         (JSC::TemplateLiteralNode::emitBytecode):
1695         * dfg/DFGByteCodeParser.cpp:
1696         (JSC::DFG::ByteCodeParser::parseBlock):
1697         * dfg/DFGCapabilities.cpp:
1698         (JSC::DFG::capabilityLevel):
1699         * jit/JIT.cpp:
1700         (JSC::JIT::privateCompileMainPass):
1701         (JSC::JIT::privateCompileSlowCases):
1702         * jit/JIT.h:
1703         * jit/JITOpcodes.cpp:
1704         (JSC::JIT::emit_op_to_string):
1705         (JSC::JIT::emitSlow_op_to_string):
1706         * jit/JITOpcodes32_64.cpp:
1707         (JSC::JIT::emit_op_to_string):
1708         (JSC::JIT::emitSlow_op_to_string):
1709         * llint/LowLevelInterpreter32_64.asm:
1710         * llint/LowLevelInterpreter64.asm:
1711         * parser/ASTBuilder.h:
1712         (JSC::ASTBuilder::createTemplateString):
1713         (JSC::ASTBuilder::createTemplateStringList):
1714         (JSC::ASTBuilder::createTemplateExpressionList):
1715         (JSC::ASTBuilder::createTemplateLiteral):
1716         * parser/Lexer.cpp:
1717         (JSC::Lexer<T>::Lexer):
1718         (JSC::Lexer<T>::parseIdentifierSlowCase):
1719         (JSC::Lexer<T>::parseString):
1720         (JSC::LineNumberAdder::LineNumberAdder):
1721         (JSC::LineNumberAdder::clear):
1722         (JSC::LineNumberAdder::add):
1723         (JSC::Lexer<T>::parseTemplateLiteral):
1724         (JSC::Lexer<T>::lex):
1725         (JSC::Lexer<T>::scanRegExp):
1726         (JSC::Lexer<T>::scanTrailingTemplateString):
1727         (JSC::Lexer<T>::parseStringSlowCase): Deleted.
1728         * parser/Lexer.h:
1729         * parser/NodeConstructors.h:
1730         (JSC::TemplateExpressionListNode::TemplateExpressionListNode):
1731         (JSC::TemplateStringNode::TemplateStringNode):
1732         (JSC::TemplateStringListNode::TemplateStringListNode):
1733         (JSC::TemplateLiteralNode::TemplateLiteralNode):
1734         * parser/Nodes.h:
1735         (JSC::TemplateExpressionListNode::value):
1736         (JSC::TemplateExpressionListNode::next):
1737         (JSC::TemplateStringNode::cooked):
1738         (JSC::TemplateStringNode::raw):
1739         (JSC::TemplateStringListNode::value):
1740         (JSC::TemplateStringListNode::next):
1741         * parser/Parser.cpp:
1742         (JSC::Parser<LexerType>::parseTemplateString):
1743         (JSC::Parser<LexerType>::parseTemplateLiteral):
1744         (JSC::Parser<LexerType>::parsePrimaryExpression):
1745         * parser/Parser.h:
1746         * parser/ParserTokens.h:
1747         * parser/SyntaxChecker.h:
1748         (JSC::SyntaxChecker::createTemplateString):
1749         (JSC::SyntaxChecker::createTemplateStringList):
1750         (JSC::SyntaxChecker::createTemplateExpressionList):
1751         (JSC::SyntaxChecker::createTemplateLiteral):
1752         (JSC::SyntaxChecker::createSpreadExpression): Deleted.
1753         * runtime/CommonSlowPaths.cpp:
1754         (JSC::SLOW_PATH_DECL):
1755         * runtime/CommonSlowPaths.h:
1756         * tests/stress/template-literal-line-terminators.js: Added.
1757         (test):
1758         (testEval):
1759         (testEvalLineNumber):
1760         * tests/stress/template-literal-syntax.js: Added.
1761         (testSyntax):
1762         (testSyntaxError):
1763         * tests/stress/template-literal.js: Added.
1764         (test):
1765         (testEval):
1766         (testEmbedded):
1767
1768 2015-04-26  Jordan Harband  <ljharb@gmail.com>
1769
1770         Set#forEach does not pass "key" or "set" arguments to callback.
1771         https://bugs.webkit.org/show_bug.cgi?id=144188
1772
1773         Reviewed by Darin Adler.
1774
1775         Per https://people.mozilla.org/~jorendorff/es6-draft.html#sec-set.prototype.foreach
1776         Set#forEach should pass 3 arguments to the callback.
1777
1778         * runtime/SetPrototype.cpp:
1779         (JSC::setProtoFuncForEach):
1780
1781 2015-04-26  Benjamin Poulain  <benjamin@webkit.org>
1782
1783         [JSC] Implement Math.clz32(), remove Number.clz()
1784         https://bugs.webkit.org/show_bug.cgi?id=144205
1785
1786         Reviewed by Michael Saboff.
1787
1788         This patch adds the ES6 function Math.clz32(), and remove the non-standard
1789         Number.clz(). Number.clz() probably came from an older draft.
1790
1791         The new function has a corresponding instrinsic: Clz32Intrinsic,
1792         and a corresponding DFG node: ArithClz32, optimized all the way to LLVM.
1793
1794         * assembler/MacroAssemblerX86Common.h:
1795         (JSC::MacroAssemblerX86Common::countLeadingZeros32):
1796         * assembler/X86Assembler.h:
1797         (JSC::X86Assembler::bsr_rr):
1798         The x86 assembler did not have countLeadingZeros32() because there is
1799         no native CLZ instruction on that architecture.
1800
1801         I have added the version with bsr + branches for the case of zero.
1802         An other popular version uses cmov to handle the case of zero. I kept
1803         it simple since the Assembler has no support for cmov.
1804
1805         It is unlikely to matter much. If the code is hot enough, LLVM picks
1806         something good based on the surrounding code.
1807
1808         * dfg/DFGAbstractInterpreterInlines.h:
1809         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
1810         Constant handling + effect propagation. The node only produces integer (between 0 and 32).
1811
1812         * dfg/DFGBackwardsPropagationPhase.cpp:
1813         (JSC::DFG::BackwardsPropagationPhase::propagate):
1814         Thanks to the definition of toUint32(), we can ignore plenty of details
1815         from doubles.
1816
1817         * dfg/DFGByteCodeParser.cpp:
1818         (JSC::DFG::ByteCodeParser::handleIntrinsic):
1819         * dfg/DFGClobberize.h:
1820         (JSC::DFG::clobberize):
1821         * dfg/DFGDoesGC.cpp:
1822         (JSC::DFG::doesGC):
1823         * dfg/DFGFixupPhase.cpp:
1824         (JSC::DFG::FixupPhase::fixupNode):
1825         * dfg/DFGNodeType.h:
1826         * dfg/DFGPredictionPropagationPhase.cpp:
1827         (JSC::DFG::PredictionPropagationPhase::propagate):
1828         * dfg/DFGSafeToExecute.h:
1829         (JSC::DFG::safeToExecute):
1830         * dfg/DFGSpeculativeJIT.cpp:
1831         (JSC::DFG::SpeculativeJIT::compileArithClz32):
1832         * dfg/DFGSpeculativeJIT.h:
1833         * dfg/DFGSpeculativeJIT32_64.cpp:
1834         (JSC::DFG::SpeculativeJIT::compile):
1835         * dfg/DFGSpeculativeJIT64.cpp:
1836         (JSC::DFG::SpeculativeJIT::compile):
1837         * ftl/FTLCapabilities.cpp:
1838         (JSC::FTL::canCompile):
1839         * ftl/FTLIntrinsicRepository.h:
1840         * ftl/FTLLowerDFGToLLVM.cpp:
1841         (JSC::FTL::LowerDFGToLLVM::compileNode):
1842         (JSC::FTL::LowerDFGToLLVM::compileArithClz32):
1843         * ftl/FTLOutput.h:
1844         (JSC::FTL::Output::ctlz32):
1845         * jit/ThunkGenerators.cpp:
1846         (JSC::clz32ThunkGenerator):
1847         * jit/ThunkGenerators.h:
1848         * runtime/Intrinsic.h:
1849         * runtime/MathCommon.h:
1850         (JSC::clz32):
1851         Fun fact: InstCombine does not recognize this pattern to eliminate
1852         the branch which makes our FTL version better than the C version.
1853
1854         * runtime/MathObject.cpp:
1855         (JSC::MathObject::finishCreation):
1856         (JSC::mathProtoFuncClz32):
1857         * runtime/NumberPrototype.cpp:
1858         (JSC::clz): Deleted.
1859         (JSC::numberProtoFuncClz): Deleted.
1860         * runtime/VM.cpp:
1861         (JSC::thunkGeneratorForIntrinsic):
1862         * tests/stress/math-clz32-basics.js: Added.
1863         (mathClz32OnInteger):
1864         (testMathClz32OnIntegers):
1865         (verifyMathClz32OnIntegerWithOtherTypes):
1866         (mathClz32OnDouble):
1867         (testMathClz32OnDoubles):
1868         (verifyMathClz32OnDoublesWithOtherTypes):
1869         (mathClz32NoArguments):
1870         (mathClz32TooManyArguments):
1871         (testMathClz32OnConstants):
1872         (mathClz32StructTransition):
1873         (Math.clz32):
1874
1875 2015-04-26  Yusuke Suzuki  <utatane.tea@gmail.com>
1876
1877         [ES6] Array.from need to accept iterables
1878         https://bugs.webkit.org/show_bug.cgi?id=141055
1879
1880         Reviewed by Darin Adler.
1881
1882         ES6 spec requires that Array.from accepts iterable objects.
1883         This patch introduces this functionality, Array.from accepting iterable objects.
1884
1885         Currently, `isConstructor` is not used. Instead of it, `typeof thiObj === "function"` is used.
1886         However, it doesn't conform to the spec. While `isConstructor` queries the given object has `[[Construct]]`,
1887         `typeof thisObj === "function"` queries the given object has `[[Call]]`.
1888         This will be fixed in the subsequent patch[1].
1889
1890         [1]: https://bugs.webkit.org/show_bug.cgi?id=144093
1891
1892         * builtins/ArrayConstructor.js:
1893         (from):
1894         * parser/Parser.cpp:
1895         (JSC::Parser<LexerType>::parseInner):
1896         * runtime/CommonIdentifiers.h:
1897         * runtime/JSGlobalObject.cpp:
1898         (JSC::JSGlobalObject::init):
1899         * tests/stress/array-from-with-iterable.js: Added.
1900         (shouldBe):
1901         (.set for):
1902         (.set var):
1903         (.get var):
1904         (argumentsGenerators):
1905         (.set shouldBe):
1906         (.set new):
1907         * tests/stress/array-from-with-iterator.js: Added.
1908         (shouldBe):
1909         (shouldThrow):
1910         (createIterator.iterator.return):
1911         (createIterator):
1912         (.):
1913
1914 2015-04-25  Jordan Harband  <ljharb@gmail.com>
1915
1916         Set#keys !== Set#values
1917         https://bugs.webkit.org/show_bug.cgi?id=144190
1918
1919         Reviewed by Darin Adler.
1920
1921         per https://people.mozilla.org/~jorendorff/es6-draft.html#sec-set.prototype.keys
1922         Set#keys should === Set#values
1923
1924         * runtime/SetPrototype.cpp:
1925         (JSC::SetPrototype::finishCreation):
1926         (JSC::setProtoFuncValues):
1927         (JSC::setProtoFuncEntries):
1928         (JSC::setProtoFuncKeys): Deleted.
1929
1930 2015-04-25  Joseph Pecoraro  <pecoraro@apple.com>
1931
1932         Allow for pausing a JSContext when opening a Web Inspector
1933         <rdar://problem/20564788>
1934
1935         Reviewed by Timothy Hatcher.
1936
1937         * inspector/remote/RemoteInspector.mm:
1938         (Inspector::RemoteInspector::receivedSetupMessage):
1939         * inspector/remote/RemoteInspectorConstants.h:
1940         * inspector/remote/RemoteInspectorDebuggable.h:
1941         * inspector/remote/RemoteInspectorDebuggableConnection.h:
1942         * inspector/remote/RemoteInspectorDebuggableConnection.mm:
1943         (Inspector::RemoteInspectorDebuggableConnection::setup):
1944         On any incoming setup message, we may want to automatically
1945         pause the debuggable. If requested, pause the debuggable
1946         after we have setup the frontend connection.
1947
1948         * runtime/JSGlobalObjectDebuggable.h:
1949         * runtime/JSGlobalObjectDebuggable.cpp:
1950         (JSC::JSGlobalObjectDebuggable::pause):
1951         Pass through to the inspector controller.
1952
1953         * inspector/JSGlobalObjectInspectorController.h:
1954         * inspector/JSGlobalObjectInspectorController.cpp:
1955         (Inspector::JSGlobalObjectInspectorController::pause):
1956         Enable pause on next statement.
1957
1958 2015-04-23  Ryosuke Niwa  <rniwa@webkit.org>
1959
1960         class methods should be non-enumerable
1961         https://bugs.webkit.org/show_bug.cgi?id=143181
1962
1963         Reviewed by Darin Adler.
1964
1965         Fixed the bug by using Object.defineProperty to define methods.
1966
1967         This patch adds the concept of link time constants and uses it to resolve Object.defineProperty
1968         inside CodeBlock's constructor since bytecode can be linked against multiple global objects.
1969
1970         * bytecode/CodeBlock.cpp: 
1971         (JSC::CodeBlock::CodeBlock): Resolve link time constants that are used. Ignore ones with register
1972         index of zero.
1973         * bytecode/SpecialPointer.h: Added a new enum for link time constants. It currently contains
1974         exactly one entry for Object.defineProperty.
1975         * bytecode/UnlinkedCodeBlock.h:
1976         (JSC::UnlinkedCodeBlock::addConstant): Added. Like addConstant that takes JSValue, allocate a new
1977         constant register for the link time constant we're adding.
1978         (JSC::UnlinkedCodeBlock::registerIndexForLinkTimeConstant): Added.
1979         * bytecompiler/BytecodeGenerator.cpp:
1980         (JSC::BytecodeGenerator::emitMoveLinkTimeConstant): Added. Like addConstantValue, allocate a new
1981         register for the specified link time constant and notify UnlinkedCodeBlock about it.
1982         (JSC::BytecodeGenerator::emitCallDefineProperty): Added. Create a new property descriptor and call
1983         Object.defineProperty with it.
1984         * bytecompiler/BytecodeGenerator.h:
1985         * bytecompiler/NodesCodegen.cpp:
1986         (JSC::PropertyListNode::emitBytecode): Make static and non-static getters and setters for classes
1987         non-enumerable by using emitCallDefineProperty to define them.
1988         (JSC::PropertyListNode::emitPutConstantProperty): Ditto for a non-accessor properties.
1989         (JSC::ClassExprNode::emitBytecode): Make prototype.constructor non-enumerable and make prototype
1990         property on the class non-writable, non-configurable, and non-enumerable by using defineProperty.
1991         * runtime/CommonIdentifiers.h:
1992         * runtime/JSGlobalObject.cpp:
1993         (JSC::JSGlobalObject::init): Set m_definePropertyFunction.
1994         (JSC::JSGlobalObject::visitChildren): Visit m_definePropertyFunction.
1995         * runtime/JSGlobalObject.h:
1996         (JSC::JSGlobalObject::definePropertyFunction): Added.
1997         (JSC::JSGlobalObject::actualPointerFor): Added a variant that takes LinkTimeConstant.
1998         (JSC::JSGlobalObject::jsCellForLinkTimeConstant): Like actualPointerFor, takes LinkTimeConstant and
1999         returns a JSCell; e.g. Object.defineProperty.
2000         * runtime/ObjectConstructor.cpp:
2001         (JSC::ObjectConstructor::addDefineProperty): Added. Returns Object.defineProperty.
2002         * runtime/ObjectConstructor.h:
2003
2004 2015-04-25  Yusuke Suzuki  <utatane.tea@gmail.com>
2005
2006         [ES6] Implement String.fromCodePoint
2007         https://bugs.webkit.org/show_bug.cgi?id=144160
2008
2009         Reviewed by Darin Adler.
2010
2011         This patch implements String.fromCodePoint.
2012         It accepts multiple code points and generates a string that consists of given code points.
2013         The range [0x0000 - 0x10FFFF] is valid for code points.
2014         If the given value is out of range, throw a range error.
2015
2016         When a 0xFFFF <= valid code point is given,
2017         String.fromCodePoint generates a string that contains surrogate pairs.
2018
2019         * runtime/StringConstructor.cpp:
2020         (JSC::stringFromCodePoint):
2021         (JSC::constructWithStringConstructor):
2022         * tests/stress/string-from-code-point.js: Added.
2023         (shouldBe):
2024         (shouldThrow):
2025         (toCodePoints):
2026         (passThrough):
2027
2028 2015-04-25  Martin Robinson  <mrobinson@igalia.com>
2029
2030         Rename ENABLE_3D_RENDERING to ENABLE_3D_TRANSFORMS
2031         https://bugs.webkit.org/show_bug.cgi?id=144182
2032
2033         Reviewed by Simon Fraser.
2034
2035         * Configurations/FeatureDefines.xcconfig: Replace all instances of 3D_RENDERING with 3D_TRANSFORMS.
2036
2037 2015-04-25  Mark Lam  <mark.lam@apple.com>
2038
2039         mayExit() is wrong about Branch nodes with ObjectOrOtherUse: they can exit.
2040         https://bugs.webkit.org/show_bug.cgi?id=144152
2041
2042         Reviewed by Filip Pizlo.
2043
2044         Changed the EdgeMayExit functor to recognize ObjectUse, ObjectOrOtherUse,
2045         StringObjectUse, and StringOrStringObjectUse kinds as potentially triggering
2046         OSR exits.  This was overlooked in the original code.
2047
2048         While only the ObjectOrOtherUse kind is relevant for manifesting this bug with
2049         the Branch node, the other 3 may also trigger the same bug for other nodes.
2050         To prevent this bug from manifesting with other nodes (and future ones that
2051         are yet to be added to mayExits()'s "potential won't exit" set), we fix the
2052         EdgeMayExit functor to handle all 4 use kinds (instead of just ObjectOrOtherUse).
2053
2054         Also added a test to exercise a code path that will trigger this bug with
2055         the Branch node before the fix is applied.
2056
2057         * dfg/DFGMayExit.cpp:
2058         * tests/stress/branch-may-exit-due-to-object-or-other-use-kind.js: Added.
2059         (inlinedFunction):
2060         (foo):
2061
2062 2015-04-24  Commit Queue  <commit-queue@webkit.org>
2063
2064         Unreviewed, rolling out r183288.
2065         https://bugs.webkit.org/show_bug.cgi?id=144189
2066
2067         Made js/sort-with-side-effecting-comparisons.html time out in
2068         debug builds (Requested by ap on #webkit).
2069
2070         Reverted changeset:
2071
2072         "It shouldn't take 1846 lines of code and 5 FIXMEs to sort an
2073         array."
2074         https://bugs.webkit.org/show_bug.cgi?id=144013
2075         http://trac.webkit.org/changeset/183288
2076
2077 2015-04-24  Filip Pizlo  <fpizlo@apple.com>
2078
2079         CRASH in operationCreateDirectArgumentsDuringExit()
2080         https://bugs.webkit.org/show_bug.cgi?id=143962
2081
2082         Reviewed by Geoffrey Garen.
2083         
2084         We shouldn't assume that constant-like OSR exit values are always recoverable. They are only
2085         recoverable so long as they are live. Therefore, OSR exit should track liveness of
2086         constants instead of assuming that they are always live.
2087
2088         * dfg/DFGGenerationInfo.h:
2089         (JSC::DFG::GenerationInfo::noticeOSRBirth):
2090         (JSC::DFG::GenerationInfo::appendBirth):
2091         * dfg/DFGSpeculativeJIT.cpp:
2092         (JSC::DFG::SpeculativeJIT::compileCurrentBlock):
2093         * dfg/DFGVariableEvent.cpp:
2094         (JSC::DFG::VariableEvent::dump):
2095         * dfg/DFGVariableEvent.h:
2096         (JSC::DFG::VariableEvent::birth):
2097         (JSC::DFG::VariableEvent::id):
2098         (JSC::DFG::VariableEvent::dataFormat):
2099         * dfg/DFGVariableEventStream.cpp:
2100         (JSC::DFG::VariableEventStream::reconstruct):
2101         * tests/stress/phantom-direct-arguments-clobber-argument-count.js: Added.
2102         (foo):
2103         (bar):
2104         * tests/stress/phantom-direct-arguments-clobber-callee.js: Added.
2105         (foo):
2106         (bar):
2107
2108 2015-04-24  Benjamin Poulain  <bpoulain@apple.com>
2109
2110         [JSC] When inserting a NaN into a Int32 array, we convert it to DoubleArray then to ContiguousArray
2111         https://bugs.webkit.org/show_bug.cgi?id=144169
2112
2113         Reviewed by Geoffrey Garen.
2114
2115         * runtime/JSObject.cpp:
2116         (JSC::JSObject::convertInt32ForValue):
2117         DoubleArray do not store NaN, they are used for holes.
2118         What happened was:
2119         1) We fail to insert the NaN in the Int32 array because it is a double.
2120         2) We were converting the array to DoubleArray.
2121         3) We were trying to insert the value again. We would fail again because
2122            DoubleArray does not store NaN.
2123         4) We would convert the DoubleArrayt to Contiguous Array, converting the values
2124            to boxed values.
2125
2126         * tests/stress/int32array-transition-on-nan.js: Added.
2127         The behavior is not really observable. This only test nothing crashes in those
2128         cases.
2129
2130         (insertNaNWhileFilling):
2131         (testInsertNaNWhileFilling):
2132         (insertNaNAfterFilling):
2133         (testInsertNaNAfterFilling):
2134         (pushNaNWhileFilling):
2135         (testPushNaNWhileFilling):
2136
2137 2015-04-21  Geoffrey Garen  <ggaren@apple.com>
2138
2139         It shouldn't take 1846 lines of code and 5 FIXMEs to sort an array.
2140         https://bugs.webkit.org/show_bug.cgi?id=144013
2141
2142         Reviewed by Mark Lam.
2143
2144         This patch implements Array.prototype.sort in JavaScript, removing the
2145         C++ implementations. It is simpler and less error-prone to express our
2146         operations in JavaScript, which provides memory safety, exception safety,
2147         and recursion safety.
2148
2149         The performance result is mixed, but net positive in my opinion. It's
2150         difficult to enumerate all the results, since we used to have so many
2151         different sorting modes, and there are lots of different data patterns
2152         across which you might want to measure sorting. Suffice it to say:
2153
2154             (*) The benchmarks we track are faster or unchanged.
2155
2156             (*) Sorting random input using a comparator -- which we think is
2157             common -- is 3X faster.
2158
2159             (*) Sorting random input in a non-array object -- which jQuery does
2160             -- is 4X faster.
2161
2162             (*) Sorting random input in a compact array of integers using a
2163             trivial pattern-matchable comparator is 2X *slower*.
2164
2165         * builtins/Array.prototype.js:
2166         (sort.min):
2167         (sort.stringComparator):
2168         (sort.compactSparse): Special case compaction for sparse arrays because
2169         we don't want to hang when sorting new Array(BIG).
2170
2171         (sort.compact):
2172         (sort.merge):
2173         (sort.mergeSort): Use merge sort because it's a reasonably efficient
2174         stable sort. We have evidence that some sites depend on stable sort,
2175         even though the ES6 spec does not mandate it. (See
2176         <http://trac.webkit.org/changeset/33967>.)
2177
2178         This is a textbook implementation of merge sort with three optimizations:
2179
2180             (1) Use iteration instead of recursion;
2181
2182             (2) Use array subscripting instead of array copying in order to
2183             create logical sub-lists without creating physical sub-lists;
2184
2185             (3) Swap src and dst at each iteration instead of copying src into
2186             dst, and only copy src into the subject array at the end if src is
2187             not the subject array.
2188
2189         (sort.inflate):
2190         (sort.comparatorSort):
2191         (sort): Sort in JavaScript for the win.
2192
2193         * builtins/BuiltinExecutables.cpp:
2194         (JSC::BuiltinExecutables::createExecutableInternal): Allow non-private
2195         names so we can use helper functions.
2196
2197         * bytecode/CodeBlock.h:
2198         (JSC::CodeBlock::isNumericCompareFunction): Deleted.
2199         * bytecode/UnlinkedCodeBlock.cpp:
2200         (JSC::UnlinkedCodeBlock::UnlinkedCodeBlock):
2201         * bytecode/UnlinkedCodeBlock.h:
2202         (JSC::UnlinkedCodeBlock::setIsNumericCompareFunction): Deleted.
2203         (JSC::UnlinkedCodeBlock::isNumericCompareFunction): Deleted.
2204         * bytecompiler/BytecodeGenerator.cpp:
2205         (JSC::BytecodeGenerator::setIsNumericCompareFunction): Deleted.
2206         * bytecompiler/BytecodeGenerator.h:
2207         * bytecompiler/NodesCodegen.cpp:
2208         (JSC::FunctionNode::emitBytecode): We don't do this special casing based
2209         on pattern matching anymore. This was mainly an optimization to avoid 
2210         the overhead of calling from C++ to JS, which we now avoid by
2211         sorting in JS.
2212
2213         * heap/Heap.cpp:
2214         (JSC::Heap::markRoots):
2215         (JSC::Heap::pushTempSortVector): Deleted.
2216         (JSC::Heap::popTempSortVector): Deleted.
2217         (JSC::Heap::visitTempSortVectors): Deleted.
2218         * heap/Heap.h: We don't have temp sort vectors anymore because we sort
2219         in JavaScript using a normal JavaScript array for our temporary storage.
2220
2221         * parser/Parser.cpp:
2222         (JSC::Parser<LexerType>::parseInner): Allow capturing so we can use
2223         helper functions.
2224
2225         * runtime/ArrayPrototype.cpp:
2226         (JSC::isNumericCompareFunction): Deleted.
2227         (JSC::attemptFastSort): Deleted.
2228         (JSC::performSlowSort): Deleted.
2229         (JSC::arrayProtoFuncSort): Deleted.
2230
2231         * runtime/CommonIdentifiers.h: New strings used by sort.
2232
2233         * runtime/JSArray.cpp:
2234         (JSC::compareNumbersForQSortWithInt32): Deleted.
2235         (JSC::compareNumbersForQSortWithDouble): Deleted.
2236         (JSC::compareNumbersForQSort): Deleted.
2237         (JSC::compareByStringPairForQSort): Deleted.
2238         (JSC::JSArray::sortNumericVector): Deleted.
2239         (JSC::JSArray::sortNumeric): Deleted.
2240         (JSC::ContiguousTypeAccessor::getAsValue): Deleted.
2241         (JSC::ContiguousTypeAccessor::setWithValue): Deleted.
2242         (JSC::ContiguousTypeAccessor::replaceDataReference): Deleted.
2243         (JSC::ContiguousTypeAccessor<ArrayWithDouble>::getAsValue): Deleted.
2244         (JSC::ContiguousTypeAccessor<ArrayWithDouble>::setWithValue): Deleted.
2245         (JSC::ContiguousTypeAccessor<ArrayWithDouble>::replaceDataReference): Deleted.
2246         (JSC::JSArray::sortCompactedVector): Deleted.
2247         (JSC::JSArray::sort): Deleted.
2248         (JSC::AVLTreeAbstractorForArrayCompare::get_less): Deleted.
2249         (JSC::AVLTreeAbstractorForArrayCompare::set_less): Deleted.
2250         (JSC::AVLTreeAbstractorForArrayCompare::get_greater): Deleted.
2251         (JSC::AVLTreeAbstractorForArrayCompare::set_greater): Deleted.
2252         (JSC::AVLTreeAbstractorForArrayCompare::get_balance_factor): Deleted.
2253         (JSC::AVLTreeAbstractorForArrayCompare::set_balance_factor): Deleted.
2254         (JSC::AVLTreeAbstractorForArrayCompare::compare_key_key): Deleted.
2255         (JSC::AVLTreeAbstractorForArrayCompare::compare_key_node): Deleted.
2256         (JSC::AVLTreeAbstractorForArrayCompare::compare_node_node): Deleted.
2257         (JSC::AVLTreeAbstractorForArrayCompare::null): Deleted.
2258         (JSC::JSArray::sortVector): Deleted.
2259         (JSC::JSArray::compactForSorting): Deleted.
2260         * runtime/JSArray.h:
2261
2262         * runtime/JSGlobalObject.cpp:
2263         (JSC::JSGlobalObject::init):
2264         * runtime/ObjectConstructor.cpp:
2265         (JSC::ObjectConstructor::finishCreation): Provide some builtins used
2266         by sort.
2267
2268 2015-04-24  Matthew Mirman  <mmirman@apple.com>
2269
2270         Made Object.prototype.__proto__ native getter and setter check that this object not null or undefined
2271         https://bugs.webkit.org/show_bug.cgi?id=141865
2272         rdar://problem/19927273
2273
2274         Reviewed by Filip Pizlo.
2275
2276         * runtime/JSGlobalObjectFunctions.cpp:
2277         (JSC::globalFuncProtoGetter):
2278         (JSC::globalFuncProtoSetter):
2279
2280 2015-04-23  Benjamin Poulain  <bpoulain@apple.com>
2281
2282         Remove a useless branch on DFGGraph::addShouldSpeculateMachineInt()
2283         https://bugs.webkit.org/show_bug.cgi?id=144118
2284
2285         Reviewed by Geoffrey Garen.
2286
2287         * dfg/DFGGraph.h:
2288         (JSC::DFG::Graph::addShouldSpeculateMachineInt):
2289         Both block do the same thing.
2290
2291 2015-04-23  Joseph Pecoraro  <pecoraro@apple.com>
2292
2293         Web Inspector: Speculative fix for non-main thread auto-attach failures
2294         https://bugs.webkit.org/show_bug.cgi?id=144134
2295
2296         Reviewed by Timothy Hatcher.
2297
2298         * inspector/remote/RemoteInspector.mm:
2299         (Inspector::RemoteInspector::singleton):
2300
2301 2015-04-23  Basile Clement  <basile_clement@apple.com>
2302
2303         Allow function allocation sinking
2304         https://bugs.webkit.org/show_bug.cgi?id=144016
2305
2306         Reviewed by Filip Pizlo.
2307
2308         This adds the ability to sink function allocations in the
2309         DFGObjectAllocationSinkingPhase.
2310
2311         In order to enable this, we add a new PhantomNewFunction node that is
2312         used similarily to the PhantomNewObject node, i.e. as a placeholder to replace
2313         a sunk NewFunction and keep track of the allocations that have to be performed
2314         in case of OSR exit after the sunk allocation but before the real one.
2315         The FunctionExecutable and JSLexicalEnvironment (activation) of the function
2316         are stored onto the PhantomNewFunction through PutHints in order for them
2317         to be recovered on OSR exit.
2318
2319         Contrary to sunk object allocations, sunk function allocations do not
2320         support any kind of operations (e.g. storing into a field) ; any such operation
2321         will mark the function allocation as escaping and trigger materialization. As
2322         such, function allocations can only be sunk to places where it would have been
2323         correct to syntactically move them, and we don't need a special
2324         MaterializeNewFunction node to recover possible operations on the function. A
2325         sunk NewFunction node will simply create new NewFunction nodes, then replace
2326         itself with a PhantomNewFunction node.
2327
2328         In itself, this change is not expected to have a significant impact on
2329         performances other than in degenerate cases (see e.g.
2330         JSRegress/sink-function), but it is a step towards being able to sink recursive
2331         closures onces we support CreateActivation sinking as well as allocation cycles
2332         sinking.
2333
2334         * dfg/DFGAbstractInterpreterInlines.h:
2335         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
2336         * dfg/DFGClobberize.h:
2337         (JSC::DFG::clobberize):
2338         * dfg/DFGDoesGC.cpp:
2339         (JSC::DFG::doesGC):
2340         * dfg/DFGFixupPhase.cpp:
2341         (JSC::DFG::FixupPhase::fixupNode):
2342         * dfg/DFGNode.h:
2343         (JSC::DFG::Node::convertToPhantomNewFunction):
2344         (JSC::DFG::Node::isPhantomAllocation):
2345         * dfg/DFGNodeType.h:
2346         * dfg/DFGObjectAllocationSinkingPhase.cpp:
2347         (JSC::DFG::ObjectAllocationSinkingPhase::lowerNonReadingOperationsOnPhantomAllocations):
2348         (JSC::DFG::ObjectAllocationSinkingPhase::handleNode):
2349         (JSC::DFG::ObjectAllocationSinkingPhase::createMaterialize):
2350         (JSC::DFG::ObjectAllocationSinkingPhase::populateMaterialize):
2351         * dfg/DFGPredictionPropagationPhase.cpp:
2352         (JSC::DFG::PredictionPropagationPhase::propagate):
2353         * dfg/DFGPromotedHeapLocation.cpp:
2354         (WTF::printInternal):
2355         * dfg/DFGPromotedHeapLocation.h:
2356         * dfg/DFGSafeToExecute.h:
2357         (JSC::DFG::safeToExecute):
2358         * dfg/DFGSpeculativeJIT32_64.cpp:
2359         (JSC::DFG::SpeculativeJIT::compile):
2360         * dfg/DFGSpeculativeJIT64.cpp:
2361         (JSC::DFG::SpeculativeJIT::compile):
2362         * dfg/DFGValidate.cpp:
2363         (JSC::DFG::Validate::validateCPS):
2364         * ftl/FTLCapabilities.cpp:
2365         (JSC::FTL::canCompile):
2366         * ftl/FTLLowerDFGToLLVM.cpp:
2367         (JSC::FTL::LowerDFGToLLVM::compileNode):
2368         * ftl/FTLOperations.cpp:
2369         (JSC::FTL::operationMaterializeObjectInOSR):
2370         * tests/stress/function-sinking-no-double-allocate.js: Added.
2371         (call):
2372         (.f):
2373         (sink):
2374         * tests/stress/function-sinking-osrexit.js: Added.
2375         (.g):
2376         (sink):
2377         * tests/stress/function-sinking-put.js: Added.
2378         (.g):
2379         (sink):
2380
2381 2015-04-23  Basile Clement  <basile_clement@apple.com>
2382
2383         Make FunctionRareData allocation thread-safe
2384         https://bugs.webkit.org/show_bug.cgi?id=144001
2385
2386         Reviewed by Mark Lam.
2387
2388         The two things we want to prevent are:
2389
2390          1. A thread seeing a pointer to a not-yet-fully-created rare data from
2391             a JSFunction
2392          2. A thread seeing a pointer to a not-yet-fully-created Structure from
2393             an ObjectAllocationProfile
2394
2395         For 1., only the JS thread can be creating the rare data (in
2396         runtime/CommonSlowPaths.cpp or in dfg/DFGOperations.cpp), so we don't need to
2397         worry about concurrent writes, and we don't need any fences when *reading* the
2398         rare data from the JS thread. Thus we only need a storeStoreFence between the
2399         rare data creation and assignment to m_rareData in
2400         JSFunction::createAndInitializeRareData() to ensure that when the store to
2401         m_rareData is issued, the rare data has been properly created.
2402
2403         For the DFG compilation threads, the only place they can access the
2404         rare data is through JSFunction::rareData(), and so we only need a
2405         loadLoadFence there to ensure that when we see a non-null pointer in
2406         m_rareData, the pointed object will be seen as a fully created
2407         FunctionRareData.
2408
2409
2410         For 2., the structure is created in
2411         ObjectAllocationProfile::initialize() (which appears to be called only by the
2412         JS thread as well, in bytecode/CodeBlock.cpp and on rare data initialization,
2413         which always happen in the JS thread), and read through
2414         ObjectAllocationProfile::structure() and
2415         ObjectAllocationProfile::inlineCapacity(), so following the same reasoning we
2416         put a storeStoreFence in ObjectAllocationProfile::initialize() and a
2417         loadLoadFence in ObjectAllocationProfile::structure() (and change
2418         ObjectAllocationProfile::inlineCapacity() to go through
2419         ObjectAllocationProfile::structure()).
2420
2421         We don't need a fence in ObjectAllocationProfile::clear() because
2422         clearing the structure is already as atomic as it gets.
2423
2424         Finally, notice that we don't care about the ObjectAllocationProfile's
2425         m_allocator as that is only used by ObjectAllocationProfile::initialize() and
2426         ObjectAllocationProfile::clear() that are always run in the JS thread.
2427         ObjectAllocationProfile::isNull() could cause some trouble, but it is
2428         currently only used in the ObjectAllocationProfile::clear()'s ASSERT in the JS
2429         thread.  Doing isNull()-style pre-checks would be wrong in any other concurrent
2430         thread anyway.
2431
2432         * bytecode/ObjectAllocationProfile.h:
2433         (JSC::ObjectAllocationProfile::initialize):
2434         (JSC::ObjectAllocationProfile::structure):
2435         (JSC::ObjectAllocationProfile::inlineCapacity):
2436         * runtime/JSFunction.cpp:
2437         (JSC::JSFunction::allocateAndInitializeRareData):
2438         * runtime/JSFunction.h:
2439         (JSC::JSFunction::rareData):
2440         (JSC::JSFunction::allocationStructure): Deleted.
2441         This is no longer used, as all the accesses to the ObjectAllocationProfile go through the rare data.
2442
2443 2015-04-22  Filip Pizlo  <fpizlo@apple.com>
2444
2445         DFG should insert Phantoms late using BytecodeKills and block-local OSR availability
2446         https://bugs.webkit.org/show_bug.cgi?id=143735
2447
2448         Reviewed by Geoffrey Garen.
2449         
2450         We've always had bugs arising from the fact that we would MovHint something into a local,
2451         and then fail to keep it alive. We would then try to keep things alive by putting Phantoms
2452         on those Nodes that were MovHinted. But this became increasingly tricky. Given the
2453         sophistication of the transformations we are doing today, this approach is just not sound
2454         anymore.
2455         
2456         This comprehensively fixes these bugs by having the DFG backend automatically insert
2457         Phantoms just before codegen based on bytecode liveness. To make this practical, this also
2458         makes it much faster to query bytecode liveness.
2459         
2460         It's about as perf-neutral as it gets for a change that increases compiler work without
2461         actually optimizing anything. Later changes will remove the old Phantom-preserving logic,
2462         which should then speed us up. I can't really report concrete slow-down numbers because
2463         they are low enough to basically be in the noise. For example, a 20-iteration run of
2464         SunSpider yields "maybe 0.8% slower", whatever that means.
2465
2466         * CMakeLists.txt:
2467         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
2468         * JavaScriptCore.xcodeproj/project.pbxproj:
2469         * bytecode/BytecodeLivenessAnalysis.cpp:
2470         (JSC::BytecodeLivenessAnalysis::computeFullLiveness):
2471         * bytecode/FullBytecodeLiveness.h:
2472         (JSC::FullBytecodeLiveness::getLiveness):
2473         * bytecode/VirtualRegister.h:
2474         (JSC::VirtualRegister::operator+):
2475         (JSC::VirtualRegister::operator-):
2476         * dfg/DFGForAllKills.h:
2477         (JSC::DFG::forAllLiveNodesAtTail):
2478         (JSC::DFG::forAllKilledOperands):
2479         (JSC::DFG::forAllKilledNodesAtNodeIndex):
2480         * dfg/DFGGraph.cpp:
2481         (JSC::DFG::Graph::isLiveInBytecode):
2482         (JSC::DFG::Graph::localsLiveInBytecode):
2483         * dfg/DFGGraph.h:
2484         (JSC::DFG::Graph::forAllLocalsLiveInBytecode):
2485         (JSC::DFG::Graph::forAllLiveInBytecode):
2486         * dfg/DFGMayExit.cpp:
2487         (JSC::DFG::mayExit):
2488         * dfg/DFGMovHintRemovalPhase.cpp:
2489         * dfg/DFGNodeType.h:
2490         * dfg/DFGPhantomInsertionPhase.cpp: Added.
2491         (JSC::DFG::performPhantomInsertion):
2492         * dfg/DFGPhantomInsertionPhase.h: Added.
2493         * dfg/DFGPlan.cpp:
2494         (JSC::DFG::Plan::compileInThreadImpl):
2495         * dfg/DFGScoreBoard.h:
2496         (JSC::DFG::ScoreBoard::sortFree):
2497         (JSC::DFG::ScoreBoard::assertClear):
2498         * dfg/DFGVirtualRegisterAllocationPhase.cpp:
2499         (JSC::DFG::VirtualRegisterAllocationPhase::run):
2500         * ftl/FTLLowerDFGToLLVM.cpp:
2501         (JSC::FTL::LowerDFGToLLVM::buildExitArguments):
2502         * tests/stress/phantom-inadequacy.js: Added.
2503         (bar):
2504         (baz):
2505         (foo):
2506
2507 2015-04-23  Filip Pizlo  <fpizlo@apple.com>
2508
2509         Rename HardPhantom to MustGenerate.
2510
2511         Rubber stamped by Geoffrey Garen.
2512         
2513         We are steadily moving towards Phantom just being a backend hack in the DFG. HardPhantom
2514         is more than that; it's a utility for forcing the execution of otherwise killable nodes.
2515         NodeMustGenerate is the flag we use to indicate that something isn't killable. So this
2516         node should just be called MustGenerate.
2517
2518         * dfg/DFGAbstractInterpreterInlines.h:
2519         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
2520         * dfg/DFGArgumentsEliminationPhase.cpp:
2521         * dfg/DFGClobberize.h:
2522         (JSC::DFG::clobberize):
2523         * dfg/DFGDCEPhase.cpp:
2524         (JSC::DFG::DCEPhase::run):
2525         * dfg/DFGDoesGC.cpp:
2526         (JSC::DFG::doesGC):
2527         * dfg/DFGFixupPhase.cpp:
2528         (JSC::DFG::FixupPhase::fixupNode):
2529         (JSC::DFG::FixupPhase::tryToRelaxRepresentation):
2530         * dfg/DFGIntegerCheckCombiningPhase.cpp:
2531         (JSC::DFG::IntegerCheckCombiningPhase::insertMustAdd):
2532         * dfg/DFGMayExit.cpp:
2533         (JSC::DFG::mayExit):
2534         * dfg/DFGNode.h:
2535         (JSC::DFG::Node::willHaveCodeGenOrOSR):
2536         * dfg/DFGNodeType.h:
2537         * dfg/DFGObjectAllocationSinkingPhase.cpp:
2538         (JSC::DFG::ObjectAllocationSinkingPhase::handleNode):
2539         * dfg/DFGPhantomCanonicalizationPhase.cpp:
2540         (JSC::DFG::PhantomCanonicalizationPhase::run):
2541         * dfg/DFGPhantomRemovalPhase.cpp:
2542         (JSC::DFG::PhantomRemovalPhase::run):
2543         * dfg/DFGPredictionPropagationPhase.cpp:
2544         (JSC::DFG::PredictionPropagationPhase::propagate):
2545         * dfg/DFGSafeToExecute.h:
2546         (JSC::DFG::safeToExecute):
2547         * dfg/DFGSpeculativeJIT32_64.cpp:
2548         (JSC::DFG::SpeculativeJIT::compile):
2549         * dfg/DFGSpeculativeJIT64.cpp:
2550         (JSC::DFG::SpeculativeJIT::compile):
2551         * dfg/DFGTypeCheckHoistingPhase.cpp:
2552         (JSC::DFG::TypeCheckHoistingPhase::identifyRedundantStructureChecks):
2553         (JSC::DFG::TypeCheckHoistingPhase::identifyRedundantArrayChecks):
2554         * dfg/DFGVarargsForwardingPhase.cpp:
2555         * ftl/FTLCapabilities.cpp:
2556         (JSC::FTL::canCompile):
2557         * ftl/FTLLowerDFGToLLVM.cpp:
2558         (JSC::FTL::LowerDFGToLLVM::compileNode):
2559
2560 2015-04-23  Jordan Harband  <ljharb@gmail.com>
2561
2562         Implement `Object.assign`
2563         https://bugs.webkit.org/show_bug.cgi?id=143980
2564
2565         Reviewed by Filip Pizlo.
2566
2567         per https://people.mozilla.org/~jorendorff/es6-draft.html#sec-object.assign
2568
2569         * builtins/ObjectConstructor.js: Added.
2570         (assign):
2571         * runtime/CommonIdentifiers.h:
2572         * runtime/JSGlobalObject.cpp:
2573         (JSC::JSGlobalObject::init):
2574         * runtime/ObjectConstructor.cpp:
2575         * runtime/ObjectConstructor.h:
2576
2577 2015-04-22  Filip Pizlo  <fpizlo@apple.com>
2578
2579         Unreviewed, fix debug build.
2580
2581         * dfg/DFGGraph.h:
2582         (JSC::DFG::Graph::performSubstitutionForEdge):
2583
2584 2015-04-22  Filip Pizlo  <fpizlo@apple.com>
2585
2586         Nodes should have an optional epoch field
2587         https://bugs.webkit.org/show_bug.cgi?id=144084
2588
2589         Reviewed by Ryosuke Niwa and Mark Lam.
2590         
2591         This makes it easier to do epoch-based analyses on nodes. I plan to do just that in
2592         https://bugs.webkit.org/show_bug.cgi?id=143735. Currently the epoch field is not yet
2593         used.
2594
2595         * dfg/DFGCPSRethreadingPhase.cpp:
2596         (JSC::DFG::CPSRethreadingPhase::canonicalizeGetLocalFor):
2597         * dfg/DFGCSEPhase.cpp:
2598         * dfg/DFGEpoch.h:
2599         (JSC::DFG::Epoch::fromUnsigned):
2600         (JSC::DFG::Epoch::toUnsigned):
2601         * dfg/DFGGraph.cpp:
2602         (JSC::DFG::Graph::clearReplacements):
2603         (JSC::DFG::Graph::clearEpochs):
2604         * dfg/DFGGraph.h:
2605         (JSC::DFG::Graph::performSubstitutionForEdge):
2606         * dfg/DFGNode.h:
2607         (JSC::DFG::Node::Node):
2608         (JSC::DFG::Node::replaceWith):
2609         (JSC::DFG::Node::replacement):
2610         (JSC::DFG::Node::setReplacement):
2611         (JSC::DFG::Node::epoch):
2612         (JSC::DFG::Node::setEpoch):
2613         * dfg/DFGSSAConversionPhase.cpp:
2614         (JSC::DFG::SSAConversionPhase::run):
2615
2616 2015-04-22  Mark Lam  <mark.lam@apple.com>
2617
2618         Fix assertion failure and race condition in Options::dumpSourceAtDFGTime().
2619         https://bugs.webkit.org/show_bug.cgi?id=143898
2620
2621         Reviewed by Filip Pizlo.
2622
2623         CodeBlock::dumpSource() will access SourceCode strings in a way that requires
2624         ref'ing of the underlying StringImpls. This is unsafe to do from arbitrary
2625         compilation threads because StringImpls are not thread safe. As a result, we get
2626         an assertion failure when we run with JSC_dumpSourceAtDFGTime=true on a debug
2627         build.
2628
2629         This patch fixes the issue by only collecting the CodeBlock (and associated info)
2630         into a DeferredSourceDump record while compiling, and stashing it away in a
2631         deferredSourceDump list in the DeferredCompilationCallback object to be dumped
2632         later.
2633
2634         When compilation is done, the callback object will be notified that
2635         compilationDidComplete().  We will dump the SourceCode strings from there. 
2636         Since compilationDidComplete() is guaranteed to only be called on the thread
2637         doing JS execution, it is safe to access the SourceCode strings there and ref
2638         their underlying StringImpls as needed.        
2639
2640         * CMakeLists.txt:
2641         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
2642         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
2643         * JavaScriptCore.xcodeproj/project.pbxproj:
2644         * bytecode/DeferredCompilationCallback.cpp:
2645         (JSC::DeferredCompilationCallback::compilationDidComplete):
2646         (JSC::DeferredCompilationCallback::sourceDumpInfo):
2647         (JSC::DeferredCompilationCallback::dumpCompiledSources):
2648         * bytecode/DeferredCompilationCallback.h:
2649         * bytecode/DeferredSourceDump.cpp: Added.
2650         (JSC::DeferredSourceDump::DeferredSourceDump):
2651         (JSC::DeferredSourceDump::dump):
2652         * bytecode/DeferredSourceDump.h: Added.
2653         * dfg/DFGByteCodeParser.cpp:
2654         (JSC::DFG::ByteCodeParser::parseCodeBlock):
2655         * dfg/DFGDriver.cpp:
2656         (JSC::DFG::compileImpl):
2657
2658 2015-04-22  Benjamin Poulain  <benjamin@webkit.org>
2659
2660         Implement String.codePointAt()
2661         https://bugs.webkit.org/show_bug.cgi?id=143934
2662
2663         Reviewed by Darin Adler.
2664
2665         This patch adds String.codePointAt() as defined by ES6.
2666         I opted for a C++ implementation for now.
2667
2668         * runtime/StringPrototype.cpp:
2669         (JSC::StringPrototype::finishCreation):
2670         (JSC::codePointAt):
2671         (JSC::stringProtoFuncCodePointAt):
2672
2673 2015-04-22  Mark Lam  <mark.lam@apple.com>
2674
2675         SparseArrayEntry's write barrier owner should be the SparseArrayValueMap.
2676         https://bugs.webkit.org/show_bug.cgi?id=144067
2677
2678         Reviewed by Michael Saboff.
2679
2680         Currently, there are a few places where the JSObject that owns the
2681         SparseArrayValueMap is designated as the owner of the SparseArrayEntry
2682         write barrier.  This is a bug and can result in the GC collecting the
2683         SparseArrayEntry even though it is being referenced by the
2684         SparseArrayValueMap.  This patch fixes the bug.
2685
2686         * runtime/JSObject.cpp:
2687         (JSC::JSObject::enterDictionaryIndexingModeWhenArrayStorageAlreadyExists):
2688         (JSC::JSObject::putIndexedDescriptor):
2689         * tests/stress/sparse-array-entry-update-144067.js: Added.
2690         (useMemoryToTriggerGCs):
2691         (foo):
2692
2693 2015-04-22  Mark Lam  <mark.lam@apple.com>
2694
2695         Give the heap object iterators the ability to return early.
2696         https://bugs.webkit.org/show_bug.cgi?id=144011
2697
2698         Reviewed by Michael Saboff.
2699
2700         JSDollarVMPrototype::isValidCell() uses a heap object iterator to validate
2701         candidate cell pointers, and, when in use, is called a lot more often than
2702         the normal way those iterators are used.  As a result, I see my instrumented
2703         VM killed with a SIGXCPU (CPU time limit exceeded).  This patch gives the
2704         callback functor the ability to tell the iterators to return early when the
2705         functor no longer needs to continue iterating.  With this, my instrumented
2706         VM is useful again for debugging.
2707
2708         Since heap iteration is not something that we do in a typical fast path,
2709         I don't expect this to have any noticeable impact on performance.
2710
2711         I also renamed ObjectAddressCheckFunctor to CellAddressCheckFunctor since
2712         it checks JSCell addresses, not just JSObjects.
2713
2714         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
2715         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
2716         * JavaScriptCore.xcodeproj/project.pbxproj:
2717         * debugger/Debugger.cpp:
2718         * heap/GCLogging.cpp:
2719         (JSC::LoggingFunctor::operator()):
2720         * heap/Heap.cpp:
2721         (JSC::Zombify::visit):
2722         (JSC::Zombify::operator()):
2723         * heap/HeapStatistics.cpp:
2724         (JSC::StorageStatistics::visit):
2725         (JSC::StorageStatistics::operator()):
2726         * heap/HeapVerifier.cpp:
2727         (JSC::GatherLiveObjFunctor::visit):
2728         (JSC::GatherLiveObjFunctor::operator()):
2729         * heap/MarkedBlock.cpp:
2730         (JSC::SetNewlyAllocatedFunctor::operator()):
2731         * heap/MarkedBlock.h:
2732         (JSC::MarkedBlock::forEachCell):
2733         (JSC::MarkedBlock::forEachLiveCell):
2734         (JSC::MarkedBlock::forEachDeadCell):
2735         * heap/MarkedSpace.h:
2736         (JSC::MarkedSpace::forEachLiveCell):
2737         (JSC::MarkedSpace::forEachDeadCell):
2738         * inspector/agents/InspectorRuntimeAgent.cpp:
2739         (Inspector::TypeRecompiler::visit):
2740         (Inspector::TypeRecompiler::operator()):
2741         * runtime/IterationStatus.h: Added.
2742         * runtime/JSGlobalObject.cpp:
2743         * runtime/VM.cpp:
2744         (JSC::StackPreservingRecompiler::visit):
2745         (JSC::StackPreservingRecompiler::operator()):
2746         * tools/JSDollarVMPrototype.cpp:
2747         (JSC::CellAddressCheckFunctor::CellAddressCheckFunctor):
2748         (JSC::CellAddressCheckFunctor::operator()):
2749         (JSC::JSDollarVMPrototype::isValidCell):
2750         (JSC::ObjectAddressCheckFunctor::ObjectAddressCheckFunctor): Deleted.
2751         (JSC::ObjectAddressCheckFunctor::operator()): Deleted.
2752
2753 2015-04-22  Yusuke Suzuki  <utatane.tea@gmail.com>
2754
2755         [[Set]] should be properly executed in JS builtins
2756         https://bugs.webkit.org/show_bug.cgi?id=143996
2757
2758         Reviewed by Geoffrey Garen.
2759
2760         Currently, all assignments in builtins JS code is compiled into put_by_val_direct.
2761         However,
2762
2763         1. Some functions (like Array.from) needs [[Set]]. (but it is now compiled into put_by_val_direct, [[DefineOwnProperty]]).
2764         2. It's different from the default JS behavior.
2765
2766         In this patch, we implement the bytecode intrinsic emitting put_by_val_direct and use it explicitly.
2767         And dropping the current hack for builtins.
2768
2769         * builtins/Array.prototype.js:
2770         (filter):
2771         (map):
2772         (find):
2773         * bytecompiler/BytecodeGenerator.cpp:
2774         (JSC::BytecodeGenerator::emitPutByVal):
2775         * tests/stress/array-fill-put-by-val.js: Added.
2776         (shouldThrow):
2777         (.set get array):
2778         * tests/stress/array-filter-put-by-val-direct.js: Added.
2779         (shouldBe):
2780         (.set get var):
2781         * tests/stress/array-find-does-not-lookup-twice.js: Added.
2782         (shouldBe):
2783         (shouldThrow):
2784         (.get shouldBe):
2785         * tests/stress/array-from-put-by-val-direct.js: Added.
2786         (shouldBe):
2787         (.set get var):
2788         * tests/stress/array-from-set-length.js: Added.
2789         (shouldBe):
2790         (ArrayLike):
2791         (ArrayLike.prototype.set length):
2792         (ArrayLike.prototype.get length):
2793         * tests/stress/array-map-put-by-val-direct.js: Added.
2794         (shouldBe):
2795         (.set get var):
2796
2797 2015-04-22  Basile Clement  <basile_clement@apple.com>
2798  
2799         Don't de-allocate FunctionRareData
2800         https://bugs.webkit.org/show_bug.cgi?id=144000
2801
2802         Reviewed by Michael Saboff.
2803
2804         A function rare data (containing most notably its allocation profile) is currently
2805         freed and re-allocated each time the function's prototype is cleared.
2806         This is not optimal as it means we are invalidating the watchpoint and recompiling the
2807         scope each time the prototype is cleared.
2808
2809         This makes it so that a single rare data is reused, clearing the underlying
2810         ObjectAllocationProfile instead of throwing away the whole rare data on
2811         .prototype updates.
2812
2813         * runtime/FunctionRareData.cpp:
2814         (JSC::FunctionRareData::create):
2815         (JSC::FunctionRareData::finishCreation):
2816         * runtime/FunctionRareData.h:
2817         * runtime/JSFunction.cpp:
2818         (JSC::JSFunction::allocateAndInitializeRareData):
2819         (JSC::JSFunction::initializeRareData):
2820
2821 2015-04-21  Filip Pizlo  <fpizlo@apple.com>
2822
2823         Unreviewed, fix 32-bit. Forgot to make this simple change to 32_64 as well.
2824
2825         * dfg/DFGSpeculativeJIT32_64.cpp:
2826         (JSC::DFG::SpeculativeJIT::compile):
2827
2828 2015-04-21  Filip Pizlo  <fpizlo@apple.com>
2829
2830         DFG should allow Phantoms after terminals
2831         https://bugs.webkit.org/show_bug.cgi?id=126778
2832
2833         Reviewed by Mark Lam.
2834         
2835         It's important for us to be able to place liveness-marking nodes after nodes that do
2836         things. These liveness-marking nodes are nops. Previously, we disallowed such nodes after
2837         terminals. That made things awkward, especially for Switch and Branch, which may do
2838         things that necessitate liveness markers (for example they might want to use a converted
2839         version of a value rather than the value that was MovHinted). We previously made this
2840         work by disallowing certain optimizations on Switch and Branch, which was probably a bad
2841         thing.
2842         
2843         This changes our IR to allow for the terminal to not be the last node in a block. Asking
2844         for the terminal involves a search. DFG::validate() checks that the nodes after the
2845         terminal are liveness markers that have no effects or checks.
2846         
2847         This is perf-neutral but will allow more optimizations in the future. It will also make
2848         it cleaner to fix https://bugs.webkit.org/show_bug.cgi?id=143735.
2849
2850         * dfg/DFGBasicBlock.cpp:
2851         (JSC::DFG::BasicBlock::replaceTerminal):
2852         * dfg/DFGBasicBlock.h:
2853         (JSC::DFG::BasicBlock::findTerminal):
2854         (JSC::DFG::BasicBlock::terminal):
2855         (JSC::DFG::BasicBlock::insertBeforeTerminal):
2856         (JSC::DFG::BasicBlock::numSuccessors):
2857         (JSC::DFG::BasicBlock::successor):
2858         (JSC::DFG::BasicBlock::successorForCondition):
2859         (JSC::DFG::BasicBlock::successors):
2860         (JSC::DFG::BasicBlock::last): Deleted.
2861         (JSC::DFG::BasicBlock::takeLast): Deleted.
2862         (JSC::DFG::BasicBlock::insertBeforeLast): Deleted.
2863         (JSC::DFG::BasicBlock::SuccessorsIterable::SuccessorsIterable): Deleted.
2864         (JSC::DFG::BasicBlock::SuccessorsIterable::iterator::iterator): Deleted.
2865         (JSC::DFG::BasicBlock::SuccessorsIterable::iterator::operator*): Deleted.
2866         (JSC::DFG::BasicBlock::SuccessorsIterable::iterator::operator++): Deleted.
2867         (JSC::DFG::BasicBlock::SuccessorsIterable::iterator::operator==): Deleted.
2868         (JSC::DFG::BasicBlock::SuccessorsIterable::iterator::operator!=): Deleted.
2869         (JSC::DFG::BasicBlock::SuccessorsIterable::begin): Deleted.
2870         (JSC::DFG::BasicBlock::SuccessorsIterable::end): Deleted.
2871         * dfg/DFGBasicBlockInlines.h:
2872         (JSC::DFG::BasicBlock::appendNonTerminal):
2873         (JSC::DFG::BasicBlock::replaceTerminal):
2874         * dfg/DFGByteCodeParser.cpp:
2875         (JSC::DFG::ByteCodeParser::addToGraph):
2876         (JSC::DFG::ByteCodeParser::inlineCall):
2877         (JSC::DFG::ByteCodeParser::handleInlining):
2878         (JSC::DFG::ByteCodeParser::parseBlock):
2879         (JSC::DFG::ByteCodeParser::linkBlock):
2880         (JSC::DFG::ByteCodeParser::parseCodeBlock):
2881         * dfg/DFGCFGSimplificationPhase.cpp:
2882         (JSC::DFG::CFGSimplificationPhase::run):
2883         (JSC::DFG::CFGSimplificationPhase::convertToJump):
2884         (JSC::DFG::CFGSimplificationPhase::mergeBlocks):
2885         * dfg/DFGCPSRethreadingPhase.cpp:
2886         (JSC::DFG::CPSRethreadingPhase::canonicalizeLocalsInBlock):
2887         * dfg/DFGCommon.h:
2888         (JSC::DFG::NodeAndIndex::NodeAndIndex):
2889         (JSC::DFG::NodeAndIndex::operator!):
2890         * dfg/DFGFixupPhase.cpp:
2891         (JSC::DFG::FixupPhase::fixupBlock):
2892         (JSC::DFG::FixupPhase::fixupNode):
2893         (JSC::DFG::FixupPhase::injectTypeConversionsInBlock):
2894         (JSC::DFG::FixupPhase::clearPhantomsAtEnd): Deleted.
2895         * dfg/DFGForAllKills.h:
2896         (JSC::DFG::forAllLiveNodesAtTail):
2897         * dfg/DFGGraph.cpp:
2898         (JSC::DFG::Graph::terminalsAreValid):
2899         (JSC::DFG::Graph::dumpBlockHeader):
2900         * dfg/DFGGraph.h:
2901         * dfg/DFGInPlaceAbstractState.cpp:
2902         (JSC::DFG::InPlaceAbstractState::mergeToSuccessors):
2903         * dfg/DFGLICMPhase.cpp:
2904         (JSC::DFG::LICMPhase::run):
2905         (JSC::DFG::LICMPhase::attemptHoist):
2906         * dfg/DFGMovHintRemovalPhase.cpp:
2907         * dfg/DFGNode.h:
2908         (JSC::DFG::Node::SuccessorsIterable::SuccessorsIterable):
2909         (JSC::DFG::Node::SuccessorsIterable::iterator::iterator):
2910         (JSC::DFG::Node::SuccessorsIterable::iterator::operator*):
2911         (JSC::DFG::Node::SuccessorsIterable::iterator::operator++):
2912         (JSC::DFG::Node::SuccessorsIterable::iterator::operator==):
2913         (JSC::DFG::Node::SuccessorsIterable::iterator::operator!=):
2914         (JSC::DFG::Node::SuccessorsIterable::begin):
2915         (JSC::DFG::Node::SuccessorsIterable::end):
2916         (JSC::DFG::Node::successors):
2917         * dfg/DFGObjectAllocationSinkingPhase.cpp:
2918         (JSC::DFG::ObjectAllocationSinkingPhase::determineMaterializationPoints):
2919         (JSC::DFG::ObjectAllocationSinkingPhase::placeMaterializationPoints):
2920         (JSC::DFG::ObjectAllocationSinkingPhase::promoteSunkenFields):
2921         * dfg/DFGPhantomRemovalPhase.cpp:
2922         (JSC::DFG::PhantomRemovalPhase::run):
2923         * dfg/DFGPutStackSinkingPhase.cpp:
2924         * dfg/DFGSSAConversionPhase.cpp:
2925         (JSC::DFG::SSAConversionPhase::run):
2926         * dfg/DFGSpeculativeJIT.h:
2927         (JSC::DFG::SpeculativeJIT::detectPeepHoleBranch):
2928         * dfg/DFGSpeculativeJIT32_64.cpp:
2929         (JSC::DFG::SpeculativeJIT::compile):
2930         * dfg/DFGSpeculativeJIT64.cpp:
2931         (JSC::DFG::SpeculativeJIT::compile):
2932         * dfg/DFGStaticExecutionCountEstimationPhase.cpp:
2933         (JSC::DFG::StaticExecutionCountEstimationPhase::run):
2934         * dfg/DFGTierUpCheckInjectionPhase.cpp:
2935         (JSC::DFG::TierUpCheckInjectionPhase::run):
2936         * dfg/DFGValidate.cpp:
2937         (JSC::DFG::Validate::validate):
2938         * ftl/FTLLowerDFGToLLVM.cpp:
2939         (JSC::FTL::LowerDFGToLLVM::compileNode):
2940         * tests/stress/closure-call-exit.js: Added.
2941         (foo):
2942
2943 2015-04-21  Basile Clement  <basile_clement@apple.com>
2944
2945         PhantomNewObject should be marked NodeMustGenerate
2946         https://bugs.webkit.org/show_bug.cgi?id=143974
2947
2948         Reviewed by Filip Pizlo.
2949
2950         * dfg/DFGNode.h:
2951         (JSC::DFG::Node::convertToPhantomNewObject):
2952         Was not properly marking NodeMustGenerate when converting.
2953
2954 2015-04-21  Filip Pizlo  <fpizlo@apple.com>
2955
2956         DFG Call/ConstructForwardVarargs fails to restore the stack pointer
2957         https://bugs.webkit.org/show_bug.cgi?id=144007
2958
2959         Reviewed by Mark Lam.
2960         
2961         We were conditioning the stack pointer restoration on isVarargs, but we also need to do it
2962         if isForwardVarargs.
2963
2964         * dfg/DFGSpeculativeJIT32_64.cpp:
2965         (JSC::DFG::SpeculativeJIT::emitCall):
2966         * dfg/DFGSpeculativeJIT64.cpp:
2967         (JSC::DFG::SpeculativeJIT::emitCall):
2968         * tests/stress/varargs-then-slow-call.js: Added.
2969         (foo):
2970         (bar):
2971         (fuzz):
2972         (baz):
2973
2974 2015-04-21  Basile Clement  <basile_clement@apple.com>
2975
2976         Remove AllocationProfileWatchpoint node
2977         https://bugs.webkit.org/show_bug.cgi?id=143999
2978
2979         Reviewed by Filip Pizlo.
2980
2981         * dfg/DFGAbstractInterpreterInlines.h:
2982         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
2983         * dfg/DFGByteCodeParser.cpp:
2984         (JSC::DFG::ByteCodeParser::parseBlock):
2985         * dfg/DFGClobberize.h:
2986         (JSC::DFG::clobberize):
2987         * dfg/DFGDoesGC.cpp:
2988         (JSC::DFG::doesGC):
2989         * dfg/DFGFixupPhase.cpp:
2990         (JSC::DFG::FixupPhase::fixupNode):
2991         * dfg/DFGHeapLocation.cpp:
2992         (WTF::printInternal):
2993         * dfg/DFGHeapLocation.h:
2994         * dfg/DFGNode.h:
2995         (JSC::DFG::Node::hasCellOperand):
2996         * dfg/DFGNodeType.h:
2997         * dfg/DFGPredictionPropagationPhase.cpp:
2998         (JSC::DFG::PredictionPropagationPhase::propagate):
2999         * dfg/DFGSafeToExecute.h:
3000         (JSC::DFG::safeToExecute):
3001         * dfg/DFGSpeculativeJIT32_64.cpp:
3002         (JSC::DFG::SpeculativeJIT::compile):
3003         * dfg/DFGSpeculativeJIT64.cpp:
3004         (JSC::DFG::SpeculativeJIT::compile):
3005         * dfg/DFGWatchpointCollectionPhase.cpp:
3006         (JSC::DFG::WatchpointCollectionPhase::handle):
3007         * ftl/FTLCapabilities.cpp:
3008         (JSC::FTL::canCompile):
3009         * ftl/FTLLowerDFGToLLVM.cpp:
3010         (JSC::FTL::LowerDFGToLLVM::compileNode):
3011         * runtime/JSFunction.h:
3012         (JSC::JSFunction::rareData):
3013         (JSC::JSFunction::allocationProfileWatchpointSet): Deleted.
3014
3015 2015-04-19  Filip Pizlo  <fpizlo@apple.com>
3016
3017         MovHint should be a strong use
3018         https://bugs.webkit.org/show_bug.cgi?id=143734
3019
3020         Reviewed by Geoffrey Garen.
3021         
3022         This disables any DCE that assumes equivalence between DFG IR uses and bytecode uses. Doing
3023         so is a major step towards allowing more fancy DFG transformations and also probably fixing
3024         some bugs.
3025         
3026         Just making MovHint a strong use would also completely disable DCE. So we mitigate this by
3027         introducing a MovHint removal phase that runs in FTL.
3028         
3029         This is a slight slowdown on Octane/gbemu, but it's basically neutral on suite averages.
3030
3031         * CMakeLists.txt:
3032         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
3033         * JavaScriptCore.xcodeproj/project.pbxproj:
3034         * bytecode/CodeOrigin.cpp:
3035         (JSC::InlineCallFrame::dumpInContext):
3036         * dfg/DFGDCEPhase.cpp:
3037         (JSC::DFG::DCEPhase::fixupBlock):
3038         * dfg/DFGDisassembler.cpp:
3039         (JSC::DFG::Disassembler::createDumpList):
3040         * dfg/DFGEpoch.cpp: Added.
3041         (JSC::DFG::Epoch::dump):
3042         * dfg/DFGEpoch.h: Added.
3043         (JSC::DFG::Epoch::Epoch):
3044         (JSC::DFG::Epoch::first):
3045         (JSC::DFG::Epoch::operator!):
3046         (JSC::DFG::Epoch::next):
3047         (JSC::DFG::Epoch::bump):
3048         (JSC::DFG::Epoch::operator==):
3049         (JSC::DFG::Epoch::operator!=):
3050         * dfg/DFGMayExit.cpp:
3051         (JSC::DFG::mayExit):
3052         * dfg/DFGMovHintRemovalPhase.cpp: Added.
3053         (JSC::DFG::performMovHintRemoval):
3054         * dfg/DFGMovHintRemovalPhase.h: Added.
3055         * dfg/DFGNodeType.h:
3056         * dfg/DFGPlan.cpp:
3057         (JSC::DFG::Plan::compileInThreadImpl):
3058         * dfg/DFGSpeculativeJIT.cpp:
3059         (JSC::DFG::SpeculativeJIT::compileCurrentBlock):
3060         * dfg/DFGSpeculativeJIT64.cpp:
3061         (JSC::DFG::SpeculativeJIT::compile):
3062         * runtime/Options.h:
3063
3064 2015-04-21  Basile Clement  <basile_clement@apple.com>
3065
3066         REGRESSION (r182899): icloud.com crashes
3067         https://bugs.webkit.org/show_bug.cgi?id=143960
3068
3069         Reviewed by Filip Pizlo.
3070
3071         * runtime/JSFunction.h:
3072         (JSC::JSFunction::allocationStructure):
3073         * tests/stress/dfg-rare-data.js: Added.
3074         (F): Regression test
3075
3076 2015-04-21  Michael Saboff  <msaboff@apple.com>
3077
3078         Crash in JSC::Interpreter::execute
3079         https://bugs.webkit.org/show_bug.cgi?id=142625
3080
3081         Reviewed by Filip Pizlo.
3082
3083         We need to keep the FunctionExecutables in the code block for the eval flavor of 
3084         Interpreter::execute() in order to create the scope used to eval.
3085
3086         * bytecode/CodeBlock.cpp:
3087         (JSC::CodeBlock::jettisonFunctionDeclsAndExprs): Deleted.
3088         * bytecode/CodeBlock.h:
3089         * dfg/DFGGraph.cpp:
3090         (JSC::DFG::Graph::registerFrozenValues):
3091
3092 2015-04-21  Chris Dumez  <cdumez@apple.com>
3093
3094         Make Vector(const Vector<T, otherCapacity, otherOverflowBehaviour>&) constructor explicit
3095         https://bugs.webkit.org/show_bug.cgi?id=143970
3096
3097         Reviewed by Darin Adler.
3098
3099         Make Vector(const Vector<T, otherCapacity, otherOverflowBehaviour>&)
3100         constructor explicit as it copies the vector and it is easy to call it
3101         by mistake.
3102
3103         * bytecode/UnlinkedInstructionStream.cpp:
3104         (JSC::UnlinkedInstructionStream::UnlinkedInstructionStream):
3105         * bytecode/UnlinkedInstructionStream.h:
3106         * ftl/FTLLowerDFGToLLVM.cpp:
3107         (JSC::FTL::LowerDFGToLLVM::lower):
3108
3109 2015-04-20  Basile Clement  <basile_clement@apple.com>
3110
3111         PhantomNewObject should be marked NodeMustGenerate
3112         https://bugs.webkit.org/show_bug.cgi?id=143974
3113
3114         Reviewed by Filip Pizlo.
3115
3116         * dfg/DFGNodeType.h: Mark PhantomNewObject as NodeMustGenerate
3117
3118 2015-04-20  Joseph Pecoraro  <pecoraro@apple.com>
3119
3120         Cleanup some StringBuilder use
3121         https://bugs.webkit.org/show_bug.cgi?id=143550
3122
3123         Reviewed by Darin Adler.
3124
3125         * runtime/Symbol.cpp:
3126         (JSC::Symbol::descriptiveString):
3127         * runtime/TypeProfiler.cpp:
3128         (JSC::TypeProfiler::typeInformationForExpressionAtOffset):
3129         * runtime/TypeSet.cpp:
3130         (JSC::TypeSet::toJSONString):
3131         (JSC::StructureShape::propertyHash):
3132         (JSC::StructureShape::stringRepresentation):
3133         (JSC::StructureShape::toJSONString):
3134
3135 2015-04-20  Mark Lam  <mark.lam@apple.com>
3136
3137         Add debugging tools to test if a given pointer is a valid object and in the heap.
3138         https://bugs.webkit.org/show_bug.cgi?id=143910
3139
3140         Reviewed by Geoffrey Garen.
3141
3142         When doing debugging from lldb, sometimes, it is useful to be able to tell if a
3143         purported JSObject is really a valid object in the heap or not.  We can add the
3144         following utility functions to help:
3145             isValidCell(heap, candidate) - returns true if the candidate is a "live" cell in the heap.
3146             isInHeap(heap, candidate) - returns true if the candidate is the heap's Object space or Storage space.
3147             isInObjectSpace(heap, candidate) - returns true if the candidate is the heap's Object space.
3148             isInStorageSpace(heap, candidate) - returns true if the candidate is the heap's Storage space.
3149
3150         Also moved lldb callable debug utility function prototypes from
3151         JSDollarVMPrototype.cpp to JSDollarVMPrototype.h as static members of the
3152         JSDollarVMPrototype class.  This is so that we can conveniently #include that
3153         file to get the prototypes when we need to call them programmatically from
3154         instrumentation that we add while debugging an issue.
3155
3156         * heap/Heap.h:
3157         (JSC::Heap::storageSpace):
3158         * tools/JSDollarVMPrototype.cpp:
3159         (JSC::JSDollarVMPrototype::currentThreadOwnsJSLock):
3160         (JSC::ensureCurrentThreadOwnsJSLock):
3161         (JSC::JSDollarVMPrototype::gc):
3162         (JSC::functionGC):
3163         (JSC::JSDollarVMPrototype::edenGC):
3164         (JSC::functionEdenGC):
3165         (JSC::JSDollarVMPrototype::isInHeap):
3166         (JSC::JSDollarVMPrototype::isInObjectSpace):
3167         (JSC::JSDollarVMPrototype::isInStorageSpace):
3168         (JSC::ObjectAddressCheckFunctor::ObjectAddressCheckFunctor):
3169         (JSC::ObjectAddressCheckFunctor::operator()):
3170         (JSC::JSDollarVMPrototype::isValidCell):
3171         (JSC::JSDollarVMPrototype::isValidCodeBlock):
3172         (JSC::JSDollarVMPrototype::codeBlockForFrame):
3173         (JSC::functionCodeBlockForFrame):
3174         (JSC::codeBlockFromArg):
3175         (JSC::JSDollarVMPrototype::printCallFrame):
3176         (JSC::JSDollarVMPrototype::printStack):
3177         (JSC::JSDollarVMPrototype::printValue):
3178         (JSC::currentThreadOwnsJSLock): Deleted.
3179         (JSC::gc): Deleted.
3180         (JSC::edenGC): Deleted.
3181         (JSC::isValidCodeBlock): Deleted.
3182         (JSC::codeBlockForFrame): Deleted.
3183         (JSC::printCallFrame): Deleted.
3184         (JSC::printStack): Deleted.
3185         (JSC::printValue): Deleted.
3186         * tools/JSDollarVMPrototype.h:
3187
3188 2015-04-20  Joseph Pecoraro  <pecoraro@apple.com>
3189
3190         Web Inspector: Improve Support for WeakSet in Console
3191         https://bugs.webkit.org/show_bug.cgi?id=143951
3192
3193         Reviewed by Darin Adler.
3194
3195         * inspector/InjectedScriptSource.js:
3196         * inspector/JSInjectedScriptHost.cpp:
3197         (Inspector::JSInjectedScriptHost::subtype):
3198         (Inspector::JSInjectedScriptHost::weakSetSize):
3199         (Inspector::JSInjectedScriptHost::weakSetEntries):
3200         * inspector/JSInjectedScriptHost.h:
3201         * inspector/JSInjectedScriptHostPrototype.cpp:
3202         (Inspector::JSInjectedScriptHostPrototype::finishCreation):
3203         (Inspector::jsInjectedScriptHostPrototypeFunctionWeakSetSize):
3204         (Inspector::jsInjectedScriptHostPrototypeFunctionWeakSetEntries):
3205         Treat WeakSets like special sets.
3206
3207         * inspector/protocol/Runtime.json:
3208         Add a new object subtype, "weakset".
3209
3210 2015-04-20  Yusuke Suzuki  <utatane.tea@gmail.com>
3211
3212         HashMap storing PropertyKey StringImpl* need to use IdentifierRepHash to handle Symbols
3213         https://bugs.webkit.org/show_bug.cgi?id=143947
3214
3215         Reviewed by Darin Adler.
3216
3217         Type profiler has map between PropertyKey (StringImpl*) and offset.
3218         StringImpl* is also used for Symbol PropertyKey.
3219         So equality of hash tables is considered by interned StringImpl*'s pointer value.
3220         To do so, use IdentifierRepHash instead of StringHash.
3221
3222         * runtime/SymbolTable.h:
3223
3224 2015-04-20  Jordan Harband  <ljharb@gmail.com>
3225
3226         Implement `Object.is`
3227         https://bugs.webkit.org/show_bug.cgi?id=143865
3228
3229         Reviewed by Darin Adler.
3230
3231         Expose sameValue to JS, via Object.is
3232         https://people.mozilla.org/~jorendorff/es6-draft.html#sec-object.is
3233
3234         * runtime/ObjectConstructor.cpp:
3235         (JSC::objectConstructorIs):
3236         * runtime/PropertyDescriptor.cpp:
3237         (JSC::sameValue):
3238
3239 2015-04-19  Darin Adler  <darin@apple.com>
3240
3241         Remove all the remaining uses of OwnPtr and PassOwnPtr in JavaScriptCore
3242         https://bugs.webkit.org/show_bug.cgi?id=143941
3243
3244         Reviewed by Gyuyoung Kim.
3245
3246         * API/JSCallbackObject.h: Use unique_ptr for m_callbackObjectData.
3247         * API/JSCallbackObjectFunctions.h: Ditto.
3248
3249         * API/ObjCCallbackFunction.h: Use unique_ptr for the arguments to the
3250         create function and the constructor and for m_impl.
3251         * API/ObjCCallbackFunction.mm:
3252         (CallbackArgumentOfClass::CallbackArgumentOfClass): Streamline this
3253         class by using RetainPtr<Class>.
3254         (ArgumentTypeDelegate::typeInteger): Use make_unique.
3255         (ArgumentTypeDelegate::typeDouble): Ditto.
3256         (ArgumentTypeDelegate::typeBool): Ditto.
3257         (ArgumentTypeDelegate::typeVoid): Ditto.
3258         (ArgumentTypeDelegate::typeId): Ditto.
3259         (ArgumentTypeDelegate::typeOfClass): Ditto.
3260         (ArgumentTypeDelegate::typeBlock): Ditto.
3261         (ArgumentTypeDelegate::typeStruct): Ditto.
3262         (ResultTypeDelegate::typeInteger): Ditto.
3263         (ResultTypeDelegate::typeDouble): Ditto.
3264         (ResultTypeDelegate::typeBool): Ditto.
3265         (ResultTypeDelegate::typeVoid): Ditto.
3266         (ResultTypeDelegate::typeId): Ditto.
3267         (ResultTypeDelegate::typeOfClass): Ditto.
3268         (ResultTypeDelegate::typeBlock): Ditto.
3269         (ResultTypeDelegate::typeStruct): Ditto.
3270         (JSC::ObjCCallbackFunctionImpl::ObjCCallbackFunctionImpl): Use
3271         unique_ptr for the arguments to the constructor, m_arguments, and m_result.
3272         Use RetainPtr<Class> for m_instanceClass.
3273         (JSC::objCCallbackFunctionCallAsConstructor): Use nullptr instead of nil or 0
3274         for non-Objective-C object pointer null.
3275         (JSC::ObjCCallbackFunction::ObjCCallbackFunction): Use unique_ptr for
3276         the arguments to the constructor and for m_impl.
3277         (JSC::ObjCCallbackFunction::create): Use unique_ptr for arguments.
3278         (skipNumber): Mark this static since it's local to this source file.
3279         (objCCallbackFunctionForInvocation): Call parseObjCType without doing any
3280         explicit adoptPtr since the types in the traits are now unique_ptr. Also use
3281         nullptr instead of nil for JSObjectRef values.
3282         (objCCallbackFunctionForMethod): Tweaked comment.
3283         (objCCallbackFunctionForBlock): Use nullptr instead of 0 for JSObjectRef.
3284
3285         * bytecode/CallLinkInfo.h: Removed unneeded include of OwnPtr.h.
3286
3287         * heap/GCThread.cpp:
3288         (JSC::GCThread::GCThread): Use unique_ptr.
3289         * heap/GCThread.h: Use unique_ptr for arguments to the constructor and for
3290         m_slotVisitor and m_copyVisitor.
3291         * heap/GCThreadSharedData.cpp:
3292         (JSC::GCThreadSharedData::GCThreadSharedData): Ditto.
3293
3294         * parser/SourceProvider.h: Removed unneeded include of PassOwnPtr.h.
3295
3296 2015-04-19  Benjamin Poulain  <benjamin@webkit.org>
3297
3298         Improve the feature.json files
3299
3300         * features.json:
3301
3302 2015-04-19  Yusuke Suzuki  <utatane.tea@gmail.com>
3303
3304         Introduce bytecode intrinsics
3305         https://bugs.webkit.org/show_bug.cgi?id=143926
3306
3307         Reviewed by Filip Pizlo.
3308
3309         This patch introduces bytecode level intrinsics into builtins/*.js JS code.
3310         When implementing functions in builtins/*.js,
3311         sometimes we require lower level functionality.
3312
3313         For example, in the current Array.from, we use `result[k] = value`.
3314         The spec requires `[[DefineOwnProperty]]` operation here.
3315         However, usual `result[k] = value` is evaluated as `[[Set]]`. (`PutValue` => `[[Set]]`)
3316         So if we implement `Array.prototype[k]` getter/setter, the difference is observable.
3317
3318         Ideally, reaching here, we would like to use put_by_val_direct bytecode.
3319         However, there's no syntax to generate it directly.
3320
3321         This patch introduces bytecode level intrinsics into JSC BytecodeCompiler.
3322         Like @call, @apply, we introduce a new node, Intrinsic.
3323         These are generated when calling appropriate private symbols in privileged code.
3324         AST parser detects them and generates Intrinsic nodes and
3325         BytecodeCompiler detects them and generate required bytecodes.
3326
3327         Currently, Array.from implementation works fine without this patch.
3328         This is because when the target code is builtin JS,
3329         BytecodeGenerator emits put_by_val_direct instead of put_by_val.
3330         This solves the above issue. However, instead of solving this issue,
3331         it raises another issue; There's no way to emit `[[Set]]` operation.
3332         `[[Set]]` operation is actually used in the spec (Array.from's "length" is set by `[[Set]]`).
3333         So to implement it precisely, introducing bytecode level intrinsics is necessary.
3334
3335         In the subsequent fixes, we'll remove that special path emitting put_by_val_direct
3336         for `result[k] = value` under builtin JS environment. Instead of that special handling,
3337         use bytecode intrinsics instead. It solves problems and it is more intuitive
3338         because written JS code in builtin works as the same to the usual JS code.
3339
3340         * CMakeLists.txt:
3341     &nbs