- 01 Feb, 2016 7 commits
-
-
nikolaos authored
NonPatternRewrite was called more than once for the same AST in the case of (computed) key expressions present in object literals. As an example, in: var x = { [[...42]]: 17 }; the array containing the spread would be desugared first and then the resulting do-expression would again be desugared. This could be problematic if a computed key expression contains large nested array/object literals. R=rossberg@chromium.org BUG= Review URL: https://codereview.chromium.org/1645023002 Cr-Commit-Position: refs/heads/master@{#33632}
-
ahaas authored
The root register is needed (at least on x64) to access ExternalReferences. R=titzer@chromium.org Review URL: https://codereview.chromium.org/1641153003 Cr-Commit-Position: refs/heads/master@{#33631}
-
zhengxing.li authored
The CL #33347 (https://codereview.chromium.org/1589363002) added the RunRoundInt32ToFloat32 test case and X87 failed at it. The reason is same as the CL #31808 (issue 1430943002, X87: Change the test case for X87 float operations), please refer: https://codereview.chromium.org/1430943002/. Here is the key comments from CL #31808 Some new test cases use CheckFloatEq(...) and CheckDoubleEq(...) function for result check. When GCC compiling the CheckFloatEq() and CheckDoubleEq() function, those inlined functions has different behavior comparing with GCC ia32 build and x87 build. The major difference is sse float register still has single precision rounding semantic. While X87 register has no such rounding precsion semantic when directly use register value. The V8 turbofan JITTed has exactly same result in both X87 and IA32 port. For CHECK_EQ(a, b) function, if a and b are doubles, it will has similar behaviors like CheckFloatEq(...) and CheckDoubleEq(...) function when compiled by GCC and causes the test case fail. So we add the following sentence to do type case to keep the same precision for RunRoundInt32ToFloat32. Such as: volatile double expect = static_cast<float>(*i). BUG= Review URL: https://codereview.chromium.org/1649323002 Cr-Commit-Position: refs/heads/master@{#33630}
-
littledan authored
This patch ships the first part of RegExp subclassing--defining Symbol.{match,replace,search,split}, but keeping their original definitions which are restricted to a RegExp receiver and do not call out to the core 'exec' method. This is being shipped separately because the two sets of extension points are separate features with separate functionality. The amount of behavior which is held behind the flag is very small, just exposing the symbols as properties of Symbol--the behavior that the String methods call out to these Symbol properties has already been shipping unflagged. R=yangguo@chromium.org BUG=v8:4305,v8:4343,v8:4344,v8:4345 LOG=Y CQ_INCLUDE_TRYBOTS=tryserver.chromium.linux:linux_chromium_rel_ng;tryserver.blink:linux_blink_rel Review URL: https://codereview.chromium.org/1652793002 Cr-Commit-Position: refs/heads/master@{#33629}
-
yangguo authored
TBR=brucedawson@chromium.org Review URL: https://codereview.chromium.org/1655743002 Cr-Commit-Position: refs/heads/master@{#33628}
-
yangguo authored
In the debugger we are interested in getting the context for the current frame, which is usually a function context. To do that, we used to call Context::declaration_context, which may also return a block context. This is wrong and can lead to crashes. Instead, we now use a newly introduced Context::closure_context, which skips block contexts. This works fine for the debugger, since we have other means to find and materialize block contexts. R=rossberg@chromium.org BUG=chromium:582051 LOG=N Review URL: https://codereview.chromium.org/1648263002 Cr-Commit-Position: refs/heads/master@{#33627}
-
v8-autoroll authored
Rolling v8/tools/clang to 667833c8778efe12d3d749f5f5dfd4b10a1388a0 TBR=machenbach@chromium.org,vogelheim@chromium.org,hablich@chromium.org Review URL: https://codereview.chromium.org/1651003002 Cr-Commit-Position: refs/heads/master@{#33626}
-
- 31 Jan, 2016 1 commit
-
-
v8-autoroll authored
Rolling v8/tools/clang to f1b8960790c46bf022d178a85a88210a7b10a2a5 TBR=machenbach@chromium.org,vogelheim@chromium.org,hablich@chromium.org Review URL: https://codereview.chromium.org/1652723002 Cr-Commit-Position: refs/heads/master@{#33625}
-
- 30 Jan, 2016 2 commits
-
-
v8-autoroll authored
Rolling v8/base/trace_event/common to 3b14e6554b07defdad00c17d162c6e7121f71fbf Rolling v8/buildtools to 389b7143dbd63da3a9725e304d286b02805fc170 Rolling v8/tools/clang to 7548b22debe829cb92047725def34c50fb88ca01 TBR=machenbach@chromium.org,vogelheim@chromium.org,hablich@chromium.org Review URL: https://codereview.chromium.org/1648343004 Cr-Commit-Position: refs/heads/master@{#33624}
-
bradnelson authored
On further reflection, marking the variable proxy at call sites for foreign functions as a function is ok. Switching this. Fixed a few IntersectResults that probably should be an explicit set_bounds. BUG= https://code.google.com/p/v8/issues/detail?id=4203 TEST=test-asm-validator R=aseemgarg@chromium.org,titzer@chromium.org LOG=N Review URL: https://codereview.chromium.org/1656493002 Cr-Commit-Position: refs/heads/master@{#33623}
-
- 29 Jan, 2016 27 commits
-
-
bradnelson authored
Associate a type with foreign functions at their callsite. Associate a type with foreign variables. More pervasively forbid computation in the module body. Confirm foreign call arguments are exports. Pass zone to more Type constructors, for consistency. BUG= https://code.google.com/p/v8/issues/detail?id=4203 TEST=test-asm-validator R=aseemgarg@chromium.org,titzer@chromium.org LOG=N Review URL: https://codereview.chromium.org/1643003004 Cr-Commit-Position: refs/heads/master@{#33622}
-
thestig authored
BUG=581960 LOG=N Review URL: https://codereview.chromium.org/1642143004 Cr-Commit-Position: refs/heads/master@{#33621}
-
mbrandy authored
R=joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com BUG= Review URL: https://codereview.chromium.org/1650593002 Cr-Commit-Position: refs/heads/master@{#33620}
-
mbrandy authored
StoreP needs a scratch register for unaligned immediate offset. R=neis@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com BUG=v8:4700 LOG=n Review URL: https://codereview.chromium.org/1644863005 Cr-Commit-Position: refs/heads/master@{#33619}
-
mbrandy authored
Port cb9b8010 Original commit message: The previous versions of Math.max and Math.min made it difficult to optimize those (that's why we already have custom code in Crankshaft), and due to lack of ideas what to do about the variable number of arguments, we will probably need to stick in special code in TurboFan as well; so inlining those builtins is off the table, hence there's no real advantage in having them around as "not quite JS" with extra work necessary in the optimizing compilers to still make those builtins somewhat fast in cases where we cannot inline them (also there's a tricky deopt loop in Crankshaft related to Math.min and Math.max, but that will be dealt with later). So to sum up: Instead of trying to make Math.max and Math.min semi-fast in the optimizing compilers with weird work-arounds support %_Arguments %_ArgumentsLength, we do provide the optimal code as native builtins instead and call it a day (which gives a nice performance boost on some benchmarks). R=bmeurer@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com BUG= Review URL: https://codereview.chromium.org/1648353002 Cr-Commit-Position: refs/heads/master@{#33618}
-
mbrandy authored
Port 0637f5f6 Original commit message: If we deoptimize from TurboFan or Crankshaft into the body of a for-in loop and that for-in mode then switches to slow mode (i.e. has to call %ForInFilter), we have to record that feedback, because otherwise we might actually OSR into that loop assuming that it's fast mode still, or even worse recompile the function later when we call it again w/o having rerun the for-in loop in fullcodegen from the beginning (where was previously the only place we could learn). R=bmeurer@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com BUG=v8:3650 LOG=n Review URL: https://codereview.chromium.org/1644383002 Cr-Commit-Position: refs/heads/master@{#33617}
-
jkummerow authored
String wrappers (new String("foo")) are special objects: their string characters are accessed like elements, and they also have an elements backing store. This used to require a bunch of explicit checks like: if (obj->IsJSValue() && JSValue::cast(obj)->value()->IsString()) { /* Handle string characters */ } // Handle regular elements (for string wrappers and other objects) obj->GetElementsAccessor()->Whatever(...); This CL introduces new ElementsKinds for string wrapper objects (one for fast elements, one for dictionary elements), which allow folding the special-casing into new StringWrapperElementsAccessors. No observable change in behavior is intended. Review URL: https://codereview.chromium.org/1612323003 Cr-Commit-Position: refs/heads/master@{#33616}
-
machenbach authored
Revert of [runtime] further dismantle AccessorInfoHandling, reducing it to the single API usecase. (patchset #2 id:20001 of https://codereview.chromium.org/1643563002/ ) Reason for revert: [Sheriff] Speculative revert for breaking webkit unit tests: https://build.chromium.org/p/client.v8.fyi/builders/V8-Blink%20Linux%2064/builds/4251 Original issue's description: > [runtime] further dismantle AccessorInfoHandling, reducing it to the single API usecase. > > BUG= > > Committed: https://crrev.com/85aba7df84d397c7e47537292e6895bd8b26f440 > Cr-Commit-Position: refs/heads/master@{#33613} TBR=ishell@chromium.org,verwaest@chromium.org # Skipping CQ checks because original CL landed less than 1 days ago. NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true BUG= Review URL: https://codereview.chromium.org/1650033003 Cr-Commit-Position: refs/heads/master@{#33615}
-
littledan authored
Previously, String.prototype.normalize constructed its ICU input string as a null-terminated string. This creates a bug for strings which contain a null byte, which is allowed in ECMAScript. This patch constructs the ICU string based on its length so that the entire string is normalized. R=jshin@chromium.org BUG=v8:4654 LOG=Y Review URL: https://codereview.chromium.org/1645223003 Cr-Commit-Position: refs/heads/master@{#33614}
-
verwaest authored
BUG= Review URL: https://codereview.chromium.org/1643563002 Cr-Commit-Position: refs/heads/master@{#33613}
-
bmeurer authored
If we deoptimize from TurboFan or Crankshaft into the body of a for-in loop and that for-in mode then switches to slow mode (i.e. has to call %ForInFilter), we have to record that feedback, because otherwise we might actually OSR into that loop assuming that it's fast mode still, or even worse recompile the function later when we call it again w/o having rerun the for-in loop in fullcodegen from the beginning (where was previously the only place we could learn). R=mstarzinger@chromium.org BUG=v8:3650 LOG=n Review URL: https://codereview.chromium.org/1638303008 Cr-Commit-Position: refs/heads/master@{#33612}
-
balazs.kilvady authored
Port cb9b8010 Original commit message: The previous versions of Math.max and Math.min made it difficult to optimize those (that's why we already have custom code in Crankshaft), and due to lack of ideas what to do about the variable number of arguments, we will probably need to stick in special code in TurboFan as well; so inlining those builtins is off the table, hence there's no real advantage in having them around as "not quite JS" with extra work necessary in the optimizing compilers to still make those builtins somewhat fast in cases where we cannot inline them (also there's a tricky deopt loop in Crankshaft related to Math.min and Math.max, but that will be dealt with later). So to sum up: Instead of trying to make Math.max and Math.min semi-fast in the optimizing compilers with weird work-arounds support %_Arguments %_ArgumentsLength, we do provide the optimal code as native builtins instead and call it a day (which gives a nice performance boost on some benchmarks). BUG= Review URL: https://codereview.chromium.org/1643973002 Cr-Commit-Position: refs/heads/master@{#33611}
-
weiliang.lin authored
Also remove duplicate code Disassemble, which is already done in TF pipeline. BUG= Review URL: https://codereview.chromium.org/1634653002 Cr-Commit-Position: refs/heads/master@{#33610}
-
bmeurer authored
The for-in slow mode implementation in Crankshaft unconditionally deoptimizes when %ForInFilter returns undefined instead of just skipping the item. Even worse, there's nothing we can learn from that deopt, so we will eventually optimize again and hit exactly the same problem again once we get back to optimized code. R=mvstanton@chromium.org BUG=v8:3650 LOG=n Review URL: https://codereview.chromium.org/1647093002 Cr-Commit-Position: refs/heads/master@{#33609}
-
yangguo authored
TBR=machenbach@chromium.org NOTRY=true NOTREECHECKS=true Review URL: https://codereview.chromium.org/1648243003 Cr-Commit-Position: refs/heads/master@{#33608}
-
mstarzinger authored
This refactors how the BytecodeArrayIterator is passed to visitation methods on the BytecodeGraphBuilder. We no longer pass it explicitly, but use the field accessor instead. Note that const-ness is still preserved and visitation methods are still not able to mutate the iterator. The main goal of this refactoring is increased readability. R=rmcilroy@chromium.org Review URL: https://codereview.chromium.org/1642893004 Cr-Commit-Position: refs/heads/master@{#33607}
-
ahaas authored
The StackSlot operator allows to allocate a spill slot on the stack. We are going to use this operator to pass floats through pointers to c functions, which we need for floating point rounding in the case where the architecture does not provide rounding instructions. R=titzer@chromium.org, v8-arm-ports@googlegroups.com, v8-ppc-ports@googlegroups.com, v8-mips-ports@googlegroups.com Committed: https://crrev.com/7a693437787090d62d937b862e29521debcc5223 Cr-Commit-Position: refs/heads/master@{#33600} Review URL: https://codereview.chromium.org/1645653002 Cr-Commit-Position: refs/heads/master@{#33606}
-
mstarzinger authored
This moves the definition of the Environment class into the compilation unit because it is only used there and not needed outside, the header doesn't need to expose it. R=rmcilroy@chromium.org Review URL: https://codereview.chromium.org/1644103002 Cr-Commit-Position: refs/heads/master@{#33605}
-
yangguo authored
R=littledan@chromium.org, rossberg@chromium.org BUG=v8:2952 LOG=Y Review URL: https://codereview.chromium.org/1647773003 Cr-Commit-Position: refs/heads/master@{#33604}
-
yangguo authored
ES2015 Annex B.1.4 specifies a restricted pattern language for unicode mode. This change reflects that, based on some test262 test cases. R=littledan@chromium.org BUG=v8:2952 LOG=N Committed: https://crrev.com/e918c4ec464456a374098049ca22eac2107f6223 Cr-Commit-Position: refs/heads/master@{#33584} Review URL: https://codereview.chromium.org/1645573002 Cr-Commit-Position: refs/heads/master@{#33603}
-
xaxxon authored
Without this change, the v8::Local<> constructor will be picked up by the compiler as an option for an implicit cast for any pointer type. This leads to bad error messages when accidentally passing an erroneous pointer type to a function wanting a Local<> (complains about a pointer assignment in Local<>'s constructor as opposed to a bad type for the parameter of the function being called) and also causes ambiguity errors where none should exist when calling overloaded functions (for example a function taking either a std::string or a v8::Local<v8::Script> cannot be called with a const char * because the compiler sees both types as being constructable with a const char *). R=jochen@chromium.org BUG= Review URL: https://codereview.chromium.org/1647833005 Cr-Commit-Position: refs/heads/master@{#33602}
-
ahaas authored
Revert of [turbofan] Add the StackSlot operator to turbofan. (patchset #4 id:60001 of https://codereview.chromium.org/1645653002/ ) Reason for revert: problems on Mac64 Original issue's description: > [turbofan] Add the StackSlot operator to turbofan. > > The StackSlot operator allows to allocate a spill slot on the stack. We > are going to use this operator to pass floats through pointers to c > functions, which we need for floating point rounding in the case where > the architecture does not provide rounding instructions. > > R=titzer@chromium.org, v8-arm-ports@googlegroups.com, v8-ppc-ports@googlegroups.com, v8-mips-ports@googlegroups.com > > Committed: https://crrev.com/7a693437787090d62d937b862e29521debcc5223 > Cr-Commit-Position: refs/heads/master@{#33600} TBR=titzer@chromium.org,v8-arm-ports@googlegroups.com,v8-mips-ports@googlegroups.com,v8-ppc-ports@googlegroups.com # Skipping CQ checks because original CL landed less than 1 days ago. NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true Review URL: https://codereview.chromium.org/1644283002 Cr-Commit-Position: refs/heads/master@{#33601}
-
ahaas authored
The StackSlot operator allows to allocate a spill slot on the stack. We are going to use this operator to pass floats through pointers to c functions, which we need for floating point rounding in the case where the architecture does not provide rounding instructions. R=titzer@chromium.org, v8-arm-ports@googlegroups.com, v8-ppc-ports@googlegroups.com, v8-mips-ports@googlegroups.com Review URL: https://codereview.chromium.org/1645653002 Cr-Commit-Position: refs/heads/master@{#33600}
-
bmeurer authored
So far the for-in slow path in Crankshaft unconditionally called %ForInFilter for every iteration of the for-in loop, without paying attention to the possible enum cache equipped receiver map. So even though we iterate the enum cache FixedArray associated with the map we don't check the map, but always go to %ForInFilter. This would be perfectly fine if the enum cache FixedArray would be immutable, but due to some funny GC/runtime interaction kicking in, the enum cache can be right trimmed while we are iterating it, and the only way to detect this is to ensure that we check the map when accessing the enum cache. BUG=v8:3650,v8:4715 LOG=n Review URL: https://codereview.chromium.org/1650493002 Cr-Commit-Position: refs/heads/master@{#33599}
-
v8-autoroll authored
Rolling v8/buildtools to be55b9ad86a4a5f760895984f93f76038e08e29e Rolling v8/tools/clang to 2b2edb2dbbc5818f98972eeefd756cdcd69aa6f3 TBR=machenbach@chromium.org,vogelheim@chromium.org,hablich@chromium.org Review URL: https://codereview.chromium.org/1650463002 Cr-Commit-Position: refs/heads/master@{#33598}
-
machenbach authored
Revert of Accurately type foreign functions, and variables. (patchset #2 id:20001 of https://codereview.chromium.org/1642993002/ ) Reason for revert: [Sheriff] Breaks arm x-compile: https://build.chromium.org/p/client.v8/builders/V8%20Arm%20-%20debug%20builder/builds/7484/steps/compile/logs/stdio Original issue's description: > Accurately type foreign functions, and variables. > > Associate a type with foreign functions at their callsite. > Associate a type with foreign variables. > More pervasively forbid computation in the module body. > Confirm foreign call arguments are exports. > > BUG= https://code.google.com/p/v8/issues/detail?id=4203 > TEST=test-asm-validator > R=aseemgarg@chromium.org,titzer@chromium.org > LOG=N > > Committed: https://crrev.com/b1d43d0b31e8aea7b31261764fef5bee4ad13903 > Cr-Commit-Position: refs/heads/master@{#33596} TBR=aseemgarg@chromium.org,titzer@chromium.org,bradnelson@google.com,bradnelson@chromium.org # Skipping CQ checks because original CL landed less than 1 days ago. NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true BUG= https://code.google.com/p/v8/issues/detail?id=4203 Review URL: https://codereview.chromium.org/1648063003 Cr-Commit-Position: refs/heads/master@{#33597}
-
bradnelson authored
Associate a type with foreign functions at their callsite. Associate a type with foreign variables. More pervasively forbid computation in the module body. Confirm foreign call arguments are exports. BUG= https://code.google.com/p/v8/issues/detail?id=4203 TEST=test-asm-validator R=aseemgarg@chromium.org,titzer@chromium.org LOG=N Review URL: https://codereview.chromium.org/1642993002 Cr-Commit-Position: refs/heads/master@{#33596}
-
- 28 Jan, 2016 3 commits
-
-
titzer authored
R=ahaas@chromium.org,bradnelson@chromium.org BUG= Review URL: https://codereview.chromium.org/1644023002 Cr-Commit-Position: refs/heads/master@{#33595}
-
rmcilroy authored
Adds --trace-ignition flag which allows tracing of bytecodes as they execute. As well as printing out the bytecode, this also prints out the input and output registers to each operation. The generated output looks as follows: -> 0x350cb46d5264 (139) : 49 fc fb 03 07 Call r4, r5, #3, [7] [ accumulator -> 0x177fba00bc99 <JS Array[2]> ] [ r4 -> 0x350cb46ce099 <JS Function InstallFunctions (SharedFunctionInfo 0x350cb46470c1)> ] [ r5 -> 0x350cb46cddc1 <an Object with map 0x35fdf590a3a9> ] [ r6 -> 0x350cb46d3f11 <JS Function Proxy (SharedFunctionInfo 0x350cb46d3e61)> ] [ r7 -> 2 ] [ accumulator <- 0x350cb4604189 <undefined> ] -> 0x350cb46d5978 (47) : 4b f8 00 00 00 CallRuntime [248], r0, #0 [ accumulator -> 0x350cb4604189 <undefined> ] [ accumulator <- 0x350cb4604189 <undefined> ] -> 0x350cb46d597d (52) : 23 09 Ldar a0 [ accumulator -> 0x350cb4604189 <undefined> ] [ a0 -> 0x350cb46d3f11 <JS Function Proxy (SharedFunctionInfo 0x350cb46d3e61)> ] [ accumulator <- 0x350cb46d3f11 <JS Function Proxy (SharedFunctionInfo 0x350cb46d3e61)> ] -> 0x350cb46d597f (54) : 24 fd Star r3 [ accumulator -> 0x350cb46d3f11 <JS Function Proxy (SharedFunctionInfo 0x350cb46d3e61)> ] [ accumulator <- 0x350cb46d3f11 <JS Function Proxy (SharedFunctionInfo 0x350cb46d3e61)> ] [ r3 <- 0x350cb46d3f11 <JS Function Proxy (SharedFunctionInfo 0x350cb46d3e61)> ] Also adds support for --print_source and --print-ast to the interpreter. BUG=v8:4280 LOG=N Review URL: https://codereview.chromium.org/1640213002 Cr-Commit-Position: refs/heads/master@{#33594}
-
hpayer authored
BUG= Review URL: https://codereview.chromium.org/1649653004 Cr-Commit-Position: refs/heads/master@{#33593}
-