- 15 Mar, 2016 3 commits
-
-
mythria authored
Updates InlineTwice to declare a function and then return a function instead of using function expressions by wrapping a function with '(' and ')'. The earlier implementation would cause the function to compile immediately instead of lazy compile. Also updates cctest.status BUG=v8:4280,v8:4837,v8:4680 LOG=N Review URL: https://codereview.chromium.org/1800073002 Cr-Commit-Position: refs/heads/master@{#34790}
-
ahaas authored
The tests require the implementation of Int32PairAdd and Word32PairShl. R=titzer@chromium.org, v8-mips-ports@googlegroups.com Review URL: https://codereview.chromium.org/1804913002 Cr-Commit-Position: refs/heads/master@{#34782}
-
ahaas authored
On 32-bit systems these instructions are compiled to calls to C functions. The TF node for the function call is already generated in the wasm compiler, the lowering of the I64 parameters is done in the Int64Lowering. We use the return value of the C function to determine whether the calculation should trap or not. R=titzer@chromium.org Review URL: https://codereview.chromium.org/1804513002 Cr-Commit-Position: refs/heads/master@{#34768}
-
- 14 Mar, 2016 3 commits
-
-
ahaas authored
The previous register allocation allowed invalid register aliasing in cases where in the TF graph the node was used for multiple inputs of the Word32PairShl node. Additionally I renamed PairLsl to LslPair in the code generation for consistency. R=titzer@chromium.org, v8-arm-ports@googlegroups.com Review URL: https://codereview.chromium.org/1776393004 Cr-Commit-Position: refs/heads/master@{#34755}
-
ahaas authored
Int64Add is lowered to a new turbofan operator, Int32AddPair. The new operator takes 4 inputs an generates 2 outputs. The inputs are the low word of the left input, high word of the left input, the low word of the right input, and high word of the right input. The ouputs are the low and high word of the result of the addition. R=titzer@chromium.org, v8-arm-ports@googlegroups.com Review URL: https://codereview.chromium.org/1778493004 Cr-Commit-Position: refs/heads/master@{#34747}
-
ahaas authored
On 32-bit systems I64XConvertFXX instructions are compiled to calls to C functions. The TF node for the function call is already generated in the wasm compiler, the lowering of the I64 parameter is done in the Int64Lowering. We use the return value of the C function to determine whether the conversion should trap or not. R=titzer@chromium.org Review URL: https://codereview.chromium.org/1775903002 Cr-Commit-Position: refs/heads/master@{#34738}
-
- 10 Mar, 2016 1 commit
-
-
rossberg authored
R=mstarzinger@chromium.org,bmeurer@chromium.org,adamk@chromium.org BUG=v8:3956 LOG=Y Review URL: https://codereview.chromium.org/1773653002 Cr-Commit-Position: refs/heads/master@{#34669}
-
- 08 Mar, 2016 2 commits
-
-
verwaest authored
Also move GetProperty with string-name to JSReceiver BUG= Review URL: https://codereview.chromium.org/1775973002 Cr-Commit-Position: refs/heads/master@{#34596}
-
mstarzinger authored
This is a pure refactoring and renaming of methods in the compiler API with the goal to increase readability. Also the compiler API is moved to the top of the file, as it is the central piece in that file. R=yangguo@chromium.org Review URL: https://codereview.chromium.org/1766623004 Cr-Commit-Position: refs/heads/master@{#34579}
-
- 07 Mar, 2016 1 commit
-
-
ahaas authored
Instead of using CheckFloatEq and CheckDoubleEq directly, I introduced a macro which first stores the expected result in a volatile variable. Here are some comments of previous CLs: 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. So we add the following sentence to do type cast to keep the same precision for RunCallInt64ToFloat32/RunCallInt64ToFloat64. Such as: volatile double expect = static_cast<float>(*i). R=titzer@chromium.org, weiliang.lin@intel.com Review URL: https://codereview.chromium.org/1773513002 Cr-Commit-Position: refs/heads/master@{#34534}
-
- 04 Mar, 2016 2 commits
-
-
ahaas authored
On 32-bit systems FXXXConvertI64 instructions are compiled to calls to C functions. The TF node for the function call is already generated in the wasm compiler, the lowering of the I64 parameter is done in the Int64Lowering. R=titzer@chromium.org, yangguo@chromium.org Review URL: https://codereview.chromium.org/1738623003 Cr-Commit-Position: refs/heads/master@{#34487}
-
bmeurer authored
Add StringLessThanStub, StringLessThanOrEqualStub, StringGreaterThanStub and StringGreaterThanOrEqualStub, based on the CodeStubAssembler, and hook them up with TurboFan (and Ignition). The stubs are currently essentially comparable with the StringCompareStub, which is now obsolete. We can later extend these stubs to cover more interesting cases (i.e. two byte sequential string comparisons, etc.). R=epertoso@chromium.org Review URL: https://codereview.chromium.org/1765823002 Cr-Commit-Position: refs/heads/master@{#34485}
-
- 03 Mar, 2016 1 commit
-
-
bmeurer authored
These new stubs perform exactly the same job as the string equality case for the CompareIC, but are platform independent and usable outside of fullcodegen and Crankshaft. We use them in the StrictEqualStub and the StrictNotEqualStub instead of falling back to the runtime immediately for String comparisons, and we also use them in TurboFan to perform String equality or inequality comparisons. These stubs currently handle only internalized and one byte strings w/o going to C++, but it should be easy to add support for more string cases later, i.e. utilizing already flattened cons strings or comparing two byte strings as well. Review URL: https://codereview.chromium.org/1761823002 Cr-Commit-Position: refs/heads/master@{#34459}
-
- 02 Mar, 2016 1 commit
-
-
ahaas authored
R=titzer@chromium.org Review URL: https://codereview.chromium.org/1760613002 Cr-Commit-Position: refs/heads/master@{#34442}
-
- 01 Mar, 2016 1 commit
-
-
binji authored
This will be used for generating the Atomics builtins. BUG=v8:4614 R=jarin@chromium.org LOG=y Review URL: https://codereview.chromium.org/1705073005 Cr-Commit-Position: refs/heads/master@{#34413}
-
- 26 Feb, 2016 1 commit
-
-
bmeurer authored
The LoadBuffer operator that is used for asm.js heap access claims to return only the appropriate typed array type, but out of bounds access could make it return undefined. So far we tried to "repair" the graph later if we see that our assumption was wrong, and for various reasons that worked for some time. But now that wrong type information that is propagated earlier is picked up appropriately and thus we generate wrong code, i.e. we in the repro case we feed NaN into ChangeFloat64Uint32 and thus get 2147483648 instead of 0 (with proper JS truncation). This was always considered a temporary hack until we have a proper asm.js pipeline, but since we still run asm.js through the generic JavaScript pipeline, we have to address this now. Quickfix is to just bailout from the pipeline when we see that the LoadBuffer type was wrong, i.e. the result of LoadBuffer is not properly truncated and thus undefined or NaN would be observable. R=mstarzinger@chromium.org, jarin@chromium.org BUG=chromium:589792 LOG=y Review URL: https://codereview.chromium.org/1740123002 Cr-Commit-Position: refs/heads/master@{#34322}
-
- 25 Feb, 2016 1 commit
-
-
bmeurer authored
Migrate Math.imul, Math.fround, Math.acos, Math.asin and Math.atan to C++ builtins, as these ones call into C++ anyway and so there's no need to have this extra wrapper around it. R=yangguo@chromium.org Review URL: https://codereview.chromium.org/1731543004 Cr-Commit-Position: refs/heads/master@{#34274}
-
- 24 Feb, 2016 2 commits
-
-
mythria authored
Revert of [Interpreter] Implements calls through CallICStub in the interpreter. (patchset #15 id:270001 of https://codereview.chromium.org/1688283003/ ) Reason for revert: It is not a good idea to call CallICStub from the builtin. It might be sensitive to the frame structure. Constructing a internal frame might cause problems. It is much better to inline the code related to the type feedback vector into the builtin. Original issue's description: > [Interpreter] Implements calls through CallICStub in the interpreter. > > Calls are implemented through CallICStub to collect type feedback. Adds > a new builtin called InterpreterPushArgsAndCallIC that pushes the > arguments onto stack and calls CallICStub. > > Also adds two new bytecodes CallIC and CallICWide to indicate calls have to > go through CallICStub. > > MIPS port contributed by balazs.kilvady. > > BUG=v8:4280, v8:4680 > LOG=N > > Committed: https://crrev.com/20362a2214c11a0f2ea5141b6a79e09458939cec > Cr-Commit-Position: refs/heads/master@{#34244} TBR=rmcilroy@chromium.org,mvstanton@chromium.org,mstarzinger@chromium.org # Skipping CQ checks because original CL landed less than 1 days ago. NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true BUG=v8:4280, v8:4680 Review URL: https://codereview.chromium.org/1731253003 Cr-Commit-Position: refs/heads/master@{#34252}
-
mythria authored
Calls are implemented through CallICStub to collect type feedback. Adds a new builtin called InterpreterPushArgsAndCallIC that pushes the arguments onto stack and calls CallICStub. Also adds two new bytecodes CallIC and CallICWide to indicate calls have to go through CallICStub. MIPS port contributed by balazs.kilvady. BUG=v8:4280, v8:4680 LOG=N Review URL: https://codereview.chromium.org/1688283003 Cr-Commit-Position: refs/heads/master@{#34244}
-
- 23 Feb, 2016 1 commit
-
-
zhengxing.li authored
The CL #33796 (https://codereview.chromium.org/1628133002) added the RunRoundUint32ToFloat32 test case and X87 failed at it. The reason is same as the CL #33630 (Issue 1649323002: X87: Change the test case for X87 RunRoundInt32ToFloat32), please refer: https://codereview.chromium.org/1649323002. Here is the key comments from CL #33630: 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 RunRoundUint32ToFloat32. Such as: volatile double expect = static_cast<float>(*i). BUG= Review URL: https://codereview.chromium.org/1714413002 Cr-Commit-Position: refs/heads/master@{#34202}
-
- 19 Feb, 2016 2 commits
-
-
jarin authored
Revert of [turbofan] Connect ObjectIsNumber to effect and control chains. (patchset #1 id:1 of https://codereview.chromium.org/1709093002/ ) Reason for revert: Tanks benchmarks (e.g., Octane box2d TF). Original issue's description: > [turbofan] Connect ObjectIsNumber to effect and control chains. > > In theory, we could connect the nodes when doing > the schedule-in-the-middle pass, but that would require creating two > versions of the operator (effectful and pure). I believe we do not > lose anything by wiring the node up eagerly. > > Committed: https://crrev.com/2894e80a0a4a51a0d72e72aa48fcd01968f7949f > Cr-Commit-Position: refs/heads/master@{#34141} TBR=bmeurer@chromium.org # Skipping CQ checks because original CL landed less than 1 days ago. NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true Review URL: https://codereview.chromium.org/1718483002 Cr-Commit-Position: refs/heads/master@{#34147}
-
jarin authored
In theory, we could connect the nodes when doing the schedule-in-the-middle pass, but that would require creating two versions of the operator (effectful and pure). I believe we do not lose anything by wiring the node up eagerly. Review URL: https://codereview.chromium.org/1709093002 Cr-Commit-Position: refs/heads/master@{#34141}
-
- 18 Feb, 2016 2 commits
-
-
ahaas authored
The BufferedRawMachineAssemblerTester caused problems for the Int64Lowering. Instead we construct a TF graph now which is compiled by Pipeline::GenerateCodeForTesting. R=titzer@chromium.org Review URL: https://codereview.chromium.org/1702023002 Cr-Commit-Position: refs/heads/master@{#34107}
-
jarin authored
Review URL: https://codereview.chromium.org/1711513003 Cr-Commit-Position: refs/heads/master@{#34103}
-
- 16 Feb, 2016 5 commits
-
-
titzer authored
This CL splits up some long-running bytecode graph builder tests. There's a lot of working going on here that probably should be split up into smaller tests and/or mjsunit tests once we have the full ignition pipeline. This one just targets the top offenders for now. R=rmcilroy@chromium.org, oth@chromium.org BUG= Review URL: https://codereview.chromium.org/1699113002 Cr-Commit-Position: refs/heads/master@{#34039}
-
bmeurer authored
Drive-by-fix: Remove the (now) unused %_SetValueOf and %_JSValueGetValue intrinsics from the various compilers and the runtime. R=jarin@chromium.org Review URL: https://codereview.chromium.org/1698343002 Cr-Commit-Position: refs/heads/master@{#34037}
-
mstarzinger authored
R=bmeurer@chromium.org BUG=v8:3956 LOG=n Review URL: https://codereview.chromium.org/1693833002 Cr-Commit-Position: refs/heads/master@{#34036}
-
rodolph.perfetta authored
Let me know if this is not the right approach Review URL: https://codereview.chromium.org/1698483002 Cr-Commit-Position: refs/heads/master@{#34028}
-
danno authored
This functionality is useful for stubs that need to walk the stack. The new machine operator, LoadParentFramePointer dosn't force the currently compiling method to have a frame in contrast to LoadFramePointer. Instead, it adapts accordingly when frame elision is possible, making efficient stack walks possible without incurring a performance penalty for small stubs that can benefit from frame elision. R=bmeurer@chromium.org LOG=N Review URL: https://codereview.chromium.org/1695313002 Cr-Commit-Position: refs/heads/master@{#34014}
-
- 15 Feb, 2016 2 commits
-
-
titzer authored
R=bmeurer@chromium.org BUG= Review URL: https://codereview.chromium.org/1698063002 Cr-Commit-Position: refs/heads/master@{#33990}
-
titzer authored
R=jarin@chromium.org BUG= Review URL: https://codereview.chromium.org/1694183002 Cr-Commit-Position: refs/heads/master@{#33987}
-
- 12 Feb, 2016 4 commits
-
-
titzer authored
R=mstarzinger@chromium.org BUG= Review URL: https://codereview.chromium.org/1698473003 Cr-Commit-Position: refs/heads/master@{#33955}
-
titzer authored
R=mstarzinger@chromium.org BUG= Review URL: https://codereview.chromium.org/1692223002 Cr-Commit-Position: refs/heads/master@{#33954}
-
bmeurer authored
There are only two uses of %_ObjectEquals left, which should actually use strict equality instead, so there's no need to keep this special logic at all. R=mvstanton@chromium.org Review URL: https://codereview.chromium.org/1692193002 Cr-Commit-Position: refs/heads/master@{#33948}
-
mstarzinger authored
The tests in question have been disabled because throwing into lazy deoptimized code was borked. After recent fixes landed these tests should now pass again. R=jarin@chromium.org TEST=cctest/test-run-deopt/DeoptExceptionHandler BUG=v8:4195 LOG=n Review URL: https://codereview.chromium.org/1692873002 Cr-Commit-Position: refs/heads/master@{#33937}
-
- 10 Feb, 2016 2 commits
-
-
mstarzinger authored
The field in question is only needed when the optimizing compiler is triggered via OSR. All other paths (e.g. from bytecode stream) should not rely on the unoptimized code being present. R=yangguo@chromium.org Review URL: https://codereview.chromium.org/1685633002 Cr-Commit-Position: refs/heads/master@{#33860}
-
mstarzinger authored
This makes sure we can run through the TurboFan pipeline without having to parse the source when using the bytecode stream as input. This path is now being tested by the BytecodeGraphTester helper. R=titzer@chromium.org,rmcilroy@chromium.org Review URL: https://codereview.chromium.org/1679313002 Cr-Commit-Position: refs/heads/master@{#33856}
-
- 09 Feb, 2016 1 commit
-
-
bmeurer authored
By now only the default %TypedArray%.prototype.sort compare function and the JS implementation of SameValueZero were still using the odd %_IsMinusZero intrinsic, whose semantics both included a number check (actually HeapNumber test) plus testing if the heap number stores the special -0 value. In both cases we already know that we deal with number so we can reduce it to a simple number test for -0, which can be expressed via dividing 1 by that value and checking the sign of the result. In case of the compare function, we can be even smarter and work with the reciprocal values in case x and y are equal to 0 (although long term we should probably rewrite the fast case for the typed array sorting function in C++ anyway, which will be way, way faster than our handwritten callback-style, type-feedback polluted JS implementation). R=yangguo@chromium.org Review URL: https://codereview.chromium.org/1680783002 Cr-Commit-Position: refs/heads/master@{#33833}
-
- 08 Feb, 2016 1 commit
-
-
mythria authored
Adds implementation and tests to support const/let variables in the interpreter. BUG=v8:4280,v8:4679 LOG=N Review URL: https://codereview.chromium.org/1634153002 Cr-Commit-Position: refs/heads/master@{#33819}
-
- 06 Feb, 2016 1 commit
-
-
jing.bao authored
BUG= Review URL: https://codereview.chromium.org/1627263002 Cr-Commit-Position: refs/heads/master@{#33797}
-