- 05 Jan, 2017 1 commit
-
-
leszeks authored
Add a more efficient encoding for state values that have a large number of optimized-out inputs. Review-Url: https://codereview.chromium.org/2509623002 Cr-Commit-Position: refs/heads/master@{#42088}
-
- 11 Nov, 2016 1 commit
-
-
bmeurer authored
This adds a new ExternalPointer type, which is an Internal type that is used for ExternalReferences and other pointer values, like the pointers into the asm.js heap. It also adds a PointerConstant operator, which we use to represents these raw constants (we can probably remove that particular operator again once WebAssembly ships with the validator). R=mvstanton@chromium.org BUG=v8:5267,v8:5270 Review-Url: https://codereview.chromium.org/2494753003 Cr-Commit-Position: refs/heads/master@{#40923}
-
- 02 Nov, 2016 3 commits
-
-
danno authored
This is preparation for using TF to create builtins that handle variable number of arguments and have to remove these arguments dynamically from the stack upon return. The gist of the changes: - Added a second argument to the Return node which specifies the number of stack slots to pop upon return in addition to those specified by the Linkage of the compiled function. - Removed Tail -> Non-Tail fallback in the instruction selector. Since TF now should handles all tail-call cases except where the return value type differs, this fallback was not really useful and in fact caused unexpected behavior with variable sized argument popping, since it wasn't possible to materialize a Return node with the right pop count from the TailCall without additional context. - Modified existing Return generation to pass a constant zero as the additional pop argument since the variable pop functionality LOG=N Review-Url: https://codereview.chromium.org/2446543002 Cr-Commit-Position: refs/heads/master@{#40699}
-
bmeurer authored
R=epertoso@chromium.org Review-Url: https://codereview.chromium.org/2223873002 Cr-Commit-Position: refs/heads/master@{#40695}
-
machenbach authored
Revert of [turbofan] Support variable size argument popping in TF-generated functions (patchset #13 id:240001 of https://codereview.chromium.org/2446543002/ ) Reason for revert: Seems to break arm64 sim debug and blocks roll: https://build.chromium.org/p/client.v8.ports/builders/V8%20Linux%20-%20arm64%20-%20sim%20-%20debug/builds/3294 Original issue's description: > [turbofan] Support variable size argument removal in TF-generated functions > > This is preparation for using TF to create builtins that handle variable number of > arguments and have to remove these arguments dynamically from the stack upon > return. > > The gist of the changes: > - Added a second argument to the Return node which specifies the number of stack > slots to pop upon return in addition to those specified by the Linkage of the > compiled function. > - Removed Tail -> Non-Tail fallback in the instruction selector. Since TF now should > handles all tail-call cases except where the return value type differs, this fallback > was not really useful and in fact caused unexpected behavior with variable > sized argument popping, since it wasn't possible to materialize a Return node > with the right pop count from the TailCall without additional context. > - Modified existing Return generation to pass a constant zero as the additional > pop argument since the variable pop functionality > > LOG=N TBR=bmeurer@chromium.org,mstarzinger@chromium.org,epertoso@chromium.org,danno@chromium.org # Not skipping CQ checks because original CL landed more than 1 days ago. NOPRESUBMIT=true Review-Url: https://codereview.chromium.org/2473643002 Cr-Commit-Position: refs/heads/master@{#40691}
-
- 31 Oct, 2016 1 commit
-
-
danno authored
This is preparation for using TF to create builtins that handle variable number of arguments and have to remove these arguments dynamically from the stack upon return. The gist of the changes: - Added a second argument to the Return node which specifies the number of stack slots to pop upon return in addition to those specified by the Linkage of the compiled function. - Removed Tail -> Non-Tail fallback in the instruction selector. Since TF now should handles all tail-call cases except where the return value type differs, this fallback was not really useful and in fact caused unexpected behavior with variable sized argument popping, since it wasn't possible to materialize a Return node with the right pop count from the TailCall without additional context. - Modified existing Return generation to pass a constant zero as the additional pop argument since the variable pop functionality LOG=N Review-Url: https://codereview.chromium.org/2446543002 Cr-Commit-Position: refs/heads/master@{#40678}
-
- 01 Sep, 2016 2 commits
-
-
marja authored
Rebuilding (after touching certain files) is crazy slow because includes are out of control. Many of these files we need to rebuild are cctests which pull in more includes than they need. BUG=v8:5294 Review-Url: https://codereview.chromium.org/2304553002 Cr-Commit-Position: refs/heads/master@{#39080}
-
bmeurer authored
Now that the hole NaN is no longer represented as Float64Constant early on, we should never see such a constant node in any JS-level graph, but we will only see them after representation selection. Change Typer and SimplifiedLowering appropriately (and fix the invalid tests). R=jarin@chromium.org BUG=v8:5267 Review-Url: https://codereview.chromium.org/2299883003 Cr-Commit-Position: refs/heads/master@{#39063}
-
- 09 Aug, 2016 1 commit
-
-
bmeurer authored
Remove the useless information from the BinaryOperationHints and CompareOperationHints, and cache the JS operators appropriately. R=epertoso@chromium.org Review-Url: https://codereview.chromium.org/2228983002 Cr-Commit-Position: refs/heads/master@{#38506}
-
- 08 Aug, 2016 1 commit
-
-
bmeurer authored
This parameter was never used and doesn't seem like it would ever be useful, so it's gone now. R=epertoso@chromium.org Review-Url: https://codereview.chromium.org/2221043002 Cr-Commit-Position: refs/heads/master@{#38453}
-
- 03 Aug, 2016 1 commit
-
-
mstarzinger authored
This removes the frame state input representing the before-state from nodes having any int32 bitwise operator. Lowering that inserts number conversions of the inputs has to be disabled when deoptimization is enabled, because the frame state layout is no longer known. R=epertoso@chromium.org BUG=v8:5021,v8:4746 Review-Url: https://codereview.chromium.org/2194383004 Cr-Commit-Position: refs/heads/master@{#38280}
-
- 12 Jul, 2016 1 commit
-
-
bmeurer authored
The PlainPrimitiveToNumber operator performs a superset of the operations previously performed by the BooleanToNumber and StringToNumber operators, so we can just use the special lowering rules for PlainPrimitiveToNumber based on the input type and get rid of the specialized operators. R=jarin@chromium.org Review-Url: https://codereview.chromium.org/2139183002 Cr-Commit-Position: refs/heads/master@{#37669}
-
- 11 Jul, 2016 2 commits
-
-
mstarzinger authored
This removes the frame state input representing the before-state from nodes having any comparison operator. Lowering that inserts number conversions of the inputs has to be disabled when deoptimization is enabled, because the frame state layout is no longer known. R=jarin@chromium.org BUG=v8:5021 Review-Url: https://codereview.chromium.org/2134173002 Cr-Commit-Position: refs/heads/master@{#37646}
-
bmeurer authored
Consume Smi/Signed32 feedback for division and modulus and introduce appropriate checked operators. This is especially important for modulus where the Float64Mod operator is significantly slower than Int32Mod on most platforms. For division it's mostly important to propagate integerness, i.e. to avoid follow-up conversions between float and int32. Drive-by-fix: Use Int32Mod for the ModulusStub (and the bytecode handler) when the inputs are both Smi. R=jarin@chromium.org Review-Url: https://codereview.chromium.org/2138633002 Cr-Commit-Position: refs/heads/master@{#37621}
-
- 05 Jul, 2016 2 commits
-
-
mstarzinger authored
This removes the frame state input representing the before-state from nodes having the {JSAdd} or the {JSSubtract} operator. Lowering that inserts number conversions of the inputs has to be disabled when deoptimization is enabled, because the frame state layout is no longer known. R=jarin@chromium.org BUG=v8:5021 Review-Url: https://codereview.chromium.org/2125593002 Cr-Commit-Position: refs/heads/master@{#37522}
-
mstarzinger authored
This removes the frame state input representing the before-state from nodes having the {JSMultiply} operator. Lowering that inserts number conversions of the inputs has to be disabled when deoptimization is enabled, because the frame state layout is no longer known. R=jarin@chromium.org BUG=v8:5021 Review-Url: https://codereview.chromium.org/2111193002 Cr-Commit-Position: refs/heads/master@{#37517}
-
- 29 Jun, 2016 1 commit
-
-
bmeurer authored
This functionality is duplicated with the same functionality in SimplifiedLowering, which is kinda premature and doesn't seem to be useful. R=jarin@chromium.org Review-Url: https://codereview.chromium.org/2103323003 Cr-Commit-Position: refs/heads/master@{#37386}
-
- 16 Jun, 2016 1 commit
-
-
jarin authored
Review-Url: https://codereview.chromium.org/2035383003 Cr-Commit-Position: refs/heads/master@{#37024}
-
- 10 Jun, 2016 1 commit
-
-
jarin authored
This should solve the problem with missing checkpoints after JSToNumber (PlainPrimitiveToNumber is marked no-write, so the frame-state propagation should see through it.) Unfortunately, this also duplicates the word32- and float64-truncation magic that we have for JSToNumber in "simplified lowering". Review-Url: https://codereview.chromium.org/2059653002 Cr-Commit-Position: refs/heads/master@{#36881}
-
- 21 Mar, 2016 1 commit
-
-
bmeurer authored
Split ToNumberStub into the entry ToNumberStub, and two new stubs, StringToNumberStub and NonNumberToNumberStub, which can be used when we already know something about the input (i.e. in various branches of the code stubs, or in TurboFan graphs). Also introduce an appropriate StringToNumber simplified operator for TurboFan, that is pure and is lowered to an invocation of the newly added StringToNumberStub. R=jarin@chromium.org Review URL: https://codereview.chromium.org/1818923002 Cr-Commit-Position: refs/heads/master@{#34922}
-
- 16 Feb, 2016 1 commit
-
-
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}
-
- 15 Feb, 2016 1 commit
-
-
titzer authored
R=bmeurer@chromium.org BUG= Review URL: https://codereview.chromium.org/1698063002 Cr-Commit-Position: refs/heads/master@{#33990}
-
- 09 Dec, 2015 1 commit
-
-
jochen authored
Embedders still can use those APIs by default test-api.cc still has an exception to use the old APIs... BUG=v8:4143 R=vogelheim@chromium.org LOG=n Review URL: https://codereview.chromium.org/1505803004 Cr-Commit-Position: refs/heads/master@{#32701}
-
- 07 Dec, 2015 1 commit
-
-
bmeurer authored
The test expectations should fail consistently in both release and debug builds. DCHECK is only meant for debug-only checks in production code. R=yangguo@chromium.org Review URL: https://codereview.chromium.org/1506753002 Cr-Commit-Position: refs/heads/master@{#32639}
-
- 01 Dec, 2015 1 commit
-
-
bmeurer authored
This is the initial support for binary operation hints on javascript binary operators, i.e. JSAdd, JSSubtract and so on. The hints are extracted from the fullcodegen code object before graph building and the AstGraphBuilder puts those hints on the operators if available. R=jarin@chromium.org BUG=v8:4583 LOG=n Review URL: https://codereview.chromium.org/1487973002 Cr-Commit-Position: refs/heads/master@{#32443}
-
- 10 Nov, 2015 1 commit
-
-
sigurds authored
This patch extends the typed lowering with a specialized version of 'instanceof' that is used if the "class", i.e. the constructor function, is a known constant. Unittests check that replacement occurs as intended. Functional correctness is ensured by extensive unit tests covering instanceof already in the testsuite. TESTS=unittests/JSTypedLoweringTest.{JSInstanceOfSpecializationWithSmiCheck,JSInstanceOfSpecializationWithoutSmiCheck,JSInstanceOfNoSpecialization} Review URL: https://codereview.chromium.org/1407413014 Cr-Commit-Position: refs/heads/master@{#31916}
-
- 05 Nov, 2015 1 commit
-
-
bmeurer authored
TurboFan didn't fully support the relevant ES6 type conversion intrinsics like %_ToNumber, %_ToLength, %_ToName, %_ToString and %_ToInteger until now, we always went to the runtime instead. These intrinsics are now well supported in TurboFan, and we are even able to generate quite decent code in some cases. R=jarin@chromium.org Review URL: https://codereview.chromium.org/1428243003 Cr-Commit-Position: refs/heads/master@{#31820}
-
- 30 Oct, 2015 1 commit
-
-
mstarzinger authored
This moves all cctest files for the compiler to live in the same namespace as the components they are testing. Hence we can avoid the forbidden using directives pulling in entire namespaces. From the Google C++ style guide: "You may not use a using-directive to make all names from a namespace available". This would be covered by presubmit linter checks if build/namespaces were not blacklisted. R=bmeurer@chromium.org Review URL: https://codereview.chromium.org/1424943004 Cr-Commit-Position: refs/heads/master@{#31671}
-
- 28 Oct, 2015 1 commit
-
-
mstarzinger authored
R=jochen@chromium.org Review URL: https://codereview.chromium.org/1408283006 Cr-Commit-Position: refs/heads/master@{#31630}
-
- 27 Oct, 2015 1 commit
-
-
bmeurer authored
Currently we still (mis)used some machine operators in typed lowering (namely Word32Or, Word32Xor and Word32And). But these operators are "polymorphic" in the signedness of their inputs and output, hence the representation selection (and thereby simplified lowering) was unable to figure out whether a bitwise operation that was seen would produce an unsigned or a signed result. If such nodes also have frame state uses, the only safe choice was float64, which was not only a lot less ideal, but also the main cause of the for-in related deoptimizer loops. Adding dedicated NumberBitwiseOr, NumberBitwiseAnd and NumberBitwiseXor simplified operators not only gives us precise (and correct) typing for the bitwise operations, but also allows us to actually verify the graph properly after typed lowering. Drive-by-fix: Remove the double-to-smi magic from the Deoptimizer, which is responsible for various deopt-loops in TurboFan, and is no longer needed with the addition of the NumberBitwise operators. R=jarin@chromium.org Review URL: https://codereview.chromium.org/1422213002 Cr-Commit-Position: refs/heads/master@{#31594}
-
- 19 Oct, 2015 1 commit
-
-
mstarzinger authored
This removes all locally constructed SimplifiedOperatorBuilder instances and uses the one passed along the JSGraph. It ensures that the correct zone is used to allocate operators, no matter where the reducer is used. R=bmeurer@chromium.org Review URL: https://codereview.chromium.org/1410003002 Cr-Commit-Position: refs/heads/master@{#31355}
-
- 16 Oct, 2015 1 commit
-
-
mstarzinger authored
This fixes the lifetime of nodes created by JSGlobalSpecialization that contain a simplified operator. In the case where this reducer runs as part of the inliner, the SimplifiedOperatorBuilder was instantiated with the wrong zone. This led to use-after-free of simplified operators. To avoid such situations in the future, we decided to move this operator builder into the JSGraph and make the situation uniform with all other operator builders. R=bmeurer@chromium.org BUG=chromium:543528 LOG=n Review URL: https://codereview.chromium.org/1409993002 Cr-Commit-Position: refs/heads/master@{#31334}
-
- 05 Oct, 2015 1 commit
-
-
karl authored
Fixes: ../../test/cctest/compiler/test-js-typed-lowering.cc:224:14: error: ‘kJSTypes’ defined but not used [-Werror=unused-variable] static Type* kJSTypes[] = {Type::Undefined(), Type::Null(), Type::Boolean(), ../../src/bignum.cc: In member function ‘void v8::internal::Bignum::AssignDecimalString(Vector<const char>)’: ../../src/bignum.cc:80:6: error: assuming signed overflow does not occur when assuming that (X + c) < X is always false [-Werror=strict-overflow] ../../src/compiler/ia32/code-generator-ia32.cc:1366:3: required from here ../../src/base/logging.h:123:26: error: comparison between signed and unsigned integer expressions [-Werror=sign-compare] DEFINE_CHECK_OP_IMPL(EQ, ==) BUG= Review URL: https://codereview.chromium.org/1371823002 Cr-Commit-Position: refs/heads/master@{#31095}
-
- 29 Sep, 2015 2 commits
-
-
jarin authored
BUG=v8:4446 LOG=n Review URL: https://codereview.chromium.org/1369313004 Cr-Commit-Position: refs/heads/master@{#31006}
-
jarin authored
This is necessary because these operators can read heap (equality can actually write heap when flattening strings). BUG=v8:4446 LOG=n Review URL: https://codereview.chromium.org/1374683002 Cr-Commit-Position: refs/heads/master@{#31005}
-
- 23 Sep, 2015 3 commits
-
-
jarin authored
(Original CL: https://codereview.chromium.org/1347353003/) Unfortunately, the mips gcc gets confused by arraysize on variadic templated arguments, so we use sizeof... instead. Review URL: https://codereview.chromium.org/1366543003 Cr-Commit-Position: refs/heads/master@{#30880}
-
machenbach authored
Revert of [turbofan] Checking of input counts on node creation (patchset #4 id:60001 of https://codereview.chromium.org/1347353003/ ) Reason for revert: [Sheriff] Breaks mips cross-compile: http://build.chromium.org/p/client.v8/builders/V8%20Mips%20-%20builder/builds/4315 Original issue's description: > [turbofan] Checking of input counts on node creation > > This required fixing bunch of tests with wrong input counts. > > Committed: https://crrev.com/260ec46efd74c45cdc4b156d95086b7de06621ad > Cr-Commit-Position: refs/heads/master@{#30877} TBR=bmeurer@chromium.org,mstarzinger@chromium.org,jarin@chromium.org NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true Review URL: https://codereview.chromium.org/1362783004 Cr-Commit-Position: refs/heads/master@{#30878}
-
jarin authored
This required fixing bunch of tests with wrong input counts. Review URL: https://codereview.chromium.org/1347353003 Cr-Commit-Position: refs/heads/master@{#30877}
-
- 16 Sep, 2015 1 commit
-
-
jarin authored
Review URL: https://codereview.chromium.org/1348073002 Cr-Commit-Position: refs/heads/master@{#30764}
-
- 31 Aug, 2015 1 commit
-
-
mstarzinger authored
The usage of Unique<T> throughout the TurboFan IR does not have any advantage. There is no single point in time when they are initialized and most use-sites looked through to the underlying Handle<T> anyways. Also there already was a mixture of Handle<T> versus Unique<T> in the graph and this unifies the situation to use Handle<T> everywhere. R=bmeurer@chromium.org,titzer@chromium.org Review URL: https://codereview.chromium.org/1314473007 Cr-Commit-Position: refs/heads/master@{#30458}
-