- 28 Apr, 2017 1 commit
-
-
Mythri authored
1. Replaces --crankshaft with --opt in tests. 2. Also fixes presubmit to check for --opt flag when assertOptimized is used. 3. Updates testrunner/local/variants.py and v8_foozie.py to use --opt flag. This would mean, nooptimize variant means there are no optimizations. Not even with %OptimizeFunctionOnNextCall. Bug:v8:6325 Change-Id: I638e743d0773a6729c6b9749e2ca1e2537f12ce6 Reviewed-on: https://chromium-review.googlesource.com/490206 Commit-Queue: Mythri Alle <mythria@chromium.org> Reviewed-by: Michael Achenbach <machenbach@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#44985}
-
- 26 Jan, 2017 3 commits
-
-
ishell authored
This CL adds --crankshaft and --no-always-opt flags to the tests that use assertOptimized() and assertUnoptimized() respectively. This CL also adds presubmit checks that ensure that tests have the proper flags set. BUG=v8:5890 Review-Url: https://codereview.chromium.org/2653753007 Cr-Commit-Position: refs/heads/master@{#42709}
-
machenbach authored
Revert of [tests] Make assertOptimized()/assertUnoptimized() great again. (patchset #6 id:130042 of https://codereview.chromium.org/2654733004/ ) Reason for revert: Mac gc stress failures: https://build.chromium.org/p/client.v8/builders/V8%20Mac%20GC%20Stress/builds/11195 There's also this flake, but maybe unrelated: https://build.chromium.org/p/client.v8/builders/V8%20Win64/builds/15422 Original issue's description: > [tests] Make assertOptimized()/assertUnoptimized() great again. > > The mentioned asserts did not work properly with interpreted and turbofanned functions. > > To fix this issue %GetOptimizationStatus() now returns a set of flags instead of a single value. > > This CL also adds more helper functions to mjsunit, like isNeverOptimize(), isAlwaysOptimize(), > isOptimized(fun), etc. > > BUG=v8:5890 > > Review-Url: https://codereview.chromium.org/2654733004 > Cr-Commit-Position: refs/heads/master@{#42703} > Committed: https://chromium.googlesource.com/v8/v8/+/d1ddec785725a184fe6d01bd0813262e3ba24966 TBR=mstarzinger@chromium.org,ishell@chromium.org # Skipping CQ checks because original CL landed less than 1 days ago. NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true BUG=v8:5890 Review-Url: https://codereview.chromium.org/2655223003 Cr-Commit-Position: refs/heads/master@{#42704}
-
ishell authored
The mentioned asserts did not work properly with interpreted and turbofanned functions. To fix this issue %GetOptimizationStatus() now returns a set of flags instead of a single value. This CL also adds more helper functions to mjsunit, like isNeverOptimize(), isAlwaysOptimize(), isOptimized(fun), etc. BUG=v8:5890 Review-Url: https://codereview.chromium.org/2654733004 Cr-Commit-Position: refs/heads/master@{#42703}
-
- 19 Oct, 2015 1 commit
-
-
bmeurer authored
Native context specialization now lowers monomorphic and polymorphic accesses to data and constant data properties on object and/or prototype chain. We don't deal with accessors yet, and we also completely ignore proxies (which is compatible with what Crankshaft does). The code is more or less the straightforward implementation. We will need to refactor that and extract common patterns once the remaining bits for full load/store support is in. CQ_INCLUDE_TRYBOTS=tryserver.v8:v8_linux_nosnap_rel R=jarin@chromium.org BUG=v8:4470 LOG=n Committed: https://crrev.com/3a0bf860b7177f7abef01ff308a53603389d958e Cr-Commit-Position: refs/heads/master@{#31340} Review URL: https://codereview.chromium.org/1396333010 Cr-Commit-Position: refs/heads/master@{#31352}
-
- 16 Oct, 2015 2 commits
-
-
jarin authored
Revert of [turbofan] Initial support for monomorphic/polymorphic property loads. (patchset #3 id:100001 of https://codereview.chromium.org/1396333010/ ) Reason for revert: Waterfall redness. Original issue's description: > [turbofan] Initial support for monomorphic/polymorphic property loads. > > Native context specialization now lowers monomorphic and > polymorphic accesses to data and constant data properties on > object and/or prototype chain. We don't deal with accessors > yet, and we also completely ignore proxies (which is compatible > with what Crankshaft does). > > The code is more or less the straightforward implementation. We > will need to refactor that and extract common patterns once the > remaining bits for full load/store support is in. > > CQ_INCLUDE_TRYBOTS=tryserver.v8:v8_linux_nosnap_rel > R=jarin@chromium.org > BUG=v8:4470 > LOG=n > > Committed: https://crrev.com/3a0bf860b7177f7abef01ff308a53603389d958e > Cr-Commit-Position: refs/heads/master@{#31340} TBR=bmeurer@chromium.org NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true BUG=v8:4470 Review URL: https://codereview.chromium.org/1408123002 Cr-Commit-Position: refs/heads/master@{#31341}
-
bmeurer authored
Native context specialization now lowers monomorphic and polymorphic accesses to data and constant data properties on object and/or prototype chain. We don't deal with accessors yet, and we also completely ignore proxies (which is compatible with what Crankshaft does). The code is more or less the straightforward implementation. We will need to refactor that and extract common patterns once the remaining bits for full load/store support is in. CQ_INCLUDE_TRYBOTS=tryserver.v8:v8_linux_nosnap_rel R=jarin@chromium.org BUG=v8:4470 LOG=n Review URL: https://codereview.chromium.org/1396333010 Cr-Commit-Position: refs/heads/master@{#31340}
-
- 12 Aug, 2015 1 commit
-
-
littledan authored
This patch strengthens testing of classes by verifying that the binding that they export externally follows block scoping, as opposed to var-style scoping. The tests are based on existing tests for let and const. R=adamk LOG=N BUG=v8:3305 Review URL: https://codereview.chromium.org/1286923002 Cr-Commit-Position: refs/heads/master@{#30140}
-
- 13 Mar, 2015 1 commit
-
-
dslomov authored
We have been shipping harmony scoping for 2 Chrome releases now (M41 and M42). Time to remove the flag. R=rossberg@chromium.org LOG=Y Review URL: https://codereview.chromium.org/1007783002 Cr-Commit-Position: refs/heads/master@{#27187}
-
- 25 Feb, 2015 1 commit
-
-
arv authored
The test did not invoke the function BUG=v8:3921 LOG=N R=adamk Review URL: https://codereview.chromium.org/961463002 Cr-Commit-Position: refs/heads/master@{#26869}
-
- 05 Jun, 2014 1 commit
-
-
ulan@chromium.org authored
Patch from Steven Keuchel <keuchel@chromium.org> BUG=v8:2198 LOG=N TEST=mjsunit/harmony/block-let-crankshaft.js R=rossberg@chromium.org Review URL: https://codereview.chromium.org/307593002 git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@21684 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 24 Nov, 2011 1 commit
-
-
keuchel@chromium.org authored
This CL introduces a third mode next to the non-strict (henceforth called 'classic mode') and 'strict mode' which is called 'extended mode' as in the current ES.next specification drafts. The extended mode is based on the 'strict mode' and adds new functionality to it. This means that most of the semantics of these two modes coincide. The 'extended mode' is entered instead of the 'strict mode' during parsing when using the 'strict mode' directive "use strict" and when the the harmony-scoping flag is active. This should be changed once it is fully specified how the 'extended mode' is entered. This change introduces a new 3 valued enum LanguageMode (see globals.h) corresponding to the modes which is mostly used by the frontend code. This includes the following components: * (Pre)Parser * Compiler * SharedFunctionInfo, Scope and ScopeInfo * runtime functions: StoreContextSlot, ResolvePossiblyDirectEval, InitializeVarGlobal, DeclareGlobals The old enum StrictModeFlag is still used in the backend when the distinction between the 'strict mode' and the 'extended mode' does not matter. This includes: * SetProperty runtime function, Delete builtin * StoreIC and KeyedStoreIC * StubCache Review URL: http://codereview.chromium.org/8417035 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@10062 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 25 Oct, 2011 1 commit
-
-
keuchel@chromium.org authored
This implements block scoped 'const' declared variables in harmony mode. They have a temporal dead zone semantics similar to 'let' bindings, i.e. accessing uninitialized 'const' bindings in throws a ReferenceError. As for 'let' bindings, the semantics of 'const' bindings in global scope is not correctly implemented yet. Furthermore assignments to 'const's are silently ignored. Another CL will introduce treatment of those assignments as early errors. Review URL: http://codereview.chromium.org/7992005 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@9764 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 12 Oct, 2011 1 commit
-
-
rossberg@chromium.org authored
Shorten --harmony-block-scoping to --harmony-scoping. R=keuchel@chromium.org BUG= TEST= Review URL: http://codereview.chromium.org/8226017 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@9589 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 16 Aug, 2011 1 commit
-
-
keuchel@chromium.org authored
Implementation of the harmony block scoped let bindings as proposed here: http://wiki.ecmascript.org/doku.php?id=harmony:block_scoped_bindings Changes to the syntax are explained there. They are active under the harmony_block_scoping_ flag in the parser. Review URL: http://codereview.chromium.org/7616009 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@8944 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 11 Aug, 2011 1 commit
-
-
keuchel@chromium.org authored
BUG= TEST= Review URL: http://codereview.chromium.org/7549008 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@8911 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 28 Jul, 2011 1 commit
-
-
keuchel@chromium.org authored
BUG= TEST=mjsunit/scope-calls-eval.js Review URL: http://codereview.chromium.org/7464030 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@8756 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 01 Jul, 2011 1 commit
-
-
kmillikin@chromium.org authored
When optimizing a function defined inside a catch, we did not count the catch context as part of the context chain. R=vegorov@chromium.org BUG=1521 TEST=regress-1521 Review URL: http://codereview.chromium.org/7285032 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@8518 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 11 Apr, 2011 1 commit
-
-
jkummerow@chromium.org authored
TEST=existing unit tests still pass Review URL: http://codereview.chromium.org/6821009 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@7572 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 07 Mar, 2011 1 commit
-
-
kmillikin@chromium.org authored
When deoptimizing after a conditional expression in an effect context, we should not see the value of the conditional expression. BUG=v8:1237 Review URL: http://codereview.chromium.org/6625057 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@7082 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 17 Feb, 2011 1 commit
-
-
kmillikin@chromium.org authored
When deoptimizing to after an expression of the form (expr0 || expr1) or (expr0 && expr1) in an effect context, the unoptimized code could incorrectly see the value of the expression. Handle the short-circuit binary operators specially in effect contexts. This fixes the issue and will generate better code when the left subexpression is boolean-valued. BUG=v8:1166 Review URL: http://codereview.chromium.org/6519046 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@6831 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 20 Jan, 2011 1 commit
-
-
sgjesse@chromium.org authored
Patch by Mark Lam from Hewlett-Packard Development Company, LP Review URL: http://codereview.chromium.org/6335009 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@6412 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 05 Jan, 2011 1 commit
-
-
sgjesse@chromium.org authored
If the instanceof stub was requested to deliver true/false objects as the result instead of 0/1 then 0/1 was actually returned if the builtin INSTANCE_OF ended up being called. This is now fixed. BUG=v8:1020 TEST=test/mjsunit/regress/regress-1020.js Review URL: http://codereview.chromium.org/6014013 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@6185 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 23 Oct, 2009 1 commit
-
-
sgjesse@chromium.org authored
If we had compiled the comment instead of the code it would have worked. BUG=483 TEST=mjsunit/regress/regress-483.js Review URL: http://codereview.chromium.org/332007 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@3120 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 20 Oct, 2009 1 commit
-
-
sgjesse@chromium.org authored
The check for arguments in registers in one of the three versions of GenericBinaryOpStub::GenerateCall was plain wrong. BUG=475 TEST=mjsunit/regress/regress-475.js Review URL: http://codereview.chromium.org/307002 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@3092 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 04 Mar, 2009 1 commit
-
-
olehougaard authored
Review URL: http://codereview.chromium.org/39126 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@1416 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 26 Sep, 2008 1 commit
-
-
christian.plesner.hansen@gmail.com authored
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@386 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 09 Sep, 2008 1 commit
-
-
christian.plesner.hansen@gmail.com authored
Added presubmit step to check copyright. git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@242 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 22 Aug, 2008 1 commit
-
-
christian.plesner.hansen authored
In the shell sample don't print the result of executing a script, only evaluating expressions. Fixed issue when building samples on Windows using a shared V8 library. Added visibility option on Linux build which makes the generated library 18% smaller. Changed build system to accept multiple build modes in one build and generate seperate objects, libraries and executables for each mode. Removed deferred negation optimization (a * -b => -(a * b)) since this visibly changes operand conversion order. Improved parsing performance by introducing stack guard in preparsing. Without a stack guard preparsing always bails out with stack overflow. git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@16 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 03 Jul, 2008 1 commit
-
-
christian.plesner.hansen authored
git-svn-id: http://v8.googlecode.com/svn/trunk@2 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-