- 09 Jan, 2020 1 commit
-
-
Maya Lekova authored
Bug: v8:7790 Change-Id: Idf066adcd5c3dca3004e2eaa0d8fa389755720af Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1991490Reviewed-by:
Michael Stanton <mvstanton@chromium.org> Commit-Queue: Maya Lekova <mslekova@chromium.org> Cr-Commit-Position: refs/heads/master@{#65671}
-
- 28 Aug, 2019 1 commit
-
-
Maya Lekova authored
Bug: v8:7790 Change-Id: I666f545f4b5b7b5aeaed4ce2910240ef54f40c0e Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1773251 Commit-Queue: Maya Lekova <mslekova@chromium.org> Reviewed-by:
Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#63427}
-
- 21 May, 2019 1 commit
-
-
Yang Guo authored
Bug: v8:9247 TBR=bmeurer@chromium.org,neis@chromium.org NOPRESUBMIT=true Change-Id: Ia1e49d1aac09c4ff9e05d58fab9d08dd71198878 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1621931Reviewed-by:
Yang Guo <yangguo@chromium.org> Reviewed-by:
Benedikt Meurer <bmeurer@chromium.org> Reviewed-by:
Michael Starzinger <mstarzinger@chromium.org> Commit-Queue: Yang Guo <yangguo@chromium.org> Cr-Commit-Position: refs/heads/master@{#61682}
-
- 01 Feb, 2019 2 commits
-
-
Clemens Hammacher authored
Clean up some redundant variables after https://crrev.com/c/1449615. R=mstarzinger@chromium.org Bug: v8:8562 Change-Id: I44d46b037978f8feff7486cdc5c521c74c0a1c9e Reviewed-on: https://chromium-review.googlesource.com/c/1449617 Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Reviewed-by:
Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#59298}
-
Clemens Hammacher authored
This CL changes the usage pattern from FOR_XXX_VALUES(i) { Use(*i); } to FOR_XXX_VALUES(i) { Use(i); } which is way more intuitive. Note that the replacement in the uses was done via regular expression, so it's purely mechanical. In two locations I removed unneeded braces around the macro, because they confused clang-format. I plan to do more cleanups (remove redundant assignments within the FOR_XXX_VALUES body) in a follow-up CL. R=mstarzinger@chromium.org Bug: v8:8562 Change-Id: I4329bfcf34e5b077d19b50f4204ceb3b4340fe61 Reviewed-on: https://chromium-review.googlesource.com/c/1449615 Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Reviewed-by:
Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#59287}
-
- 18 Jul, 2018 1 commit
-
-
Leszek Swirski authored
ReadOnlyRoots means that some added Isolate parameters are no longer needed. So, we can remove them. This patch was generated mostly automatically with a bespoke tool. Bug: v8:7786 Bug: v8:7754 Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng Change-Id: Ia44fd2a66652253f780e3674bf7fb431caef0493 Reviewed-on: https://chromium-review.googlesource.com/1136305 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by:
Michael Starzinger <mstarzinger@chromium.org> Reviewed-by:
Dan Elphick <delphick@chromium.org> Reviewed-by:
Benedikt Meurer <bmeurer@chromium.org> Reviewed-by:
Yang Guo <yangguo@chromium.org> Cr-Commit-Position: refs/heads/master@{#54526}
-
- 25 Apr, 2018 1 commit
-
-
Andreas Haas authored
I missed one required change which was hidden behind an #if. The fix is in the diff between Patch 1 and Patch 3. Original message: In this CL I remove the isolate from signatures of ExternalReference accessor functions where the isolate is not used. The uses of the isolate were already removed in previous CLs. Changes: * I split the ExternalReference list in external-reference.h into those which need the isolate for initialization and those which do not. * I removed the public constructors and replaced them by ExternalReference::Create(). The reason is to separate external creation more clearly from internal creation, because externally created ExternalReferences sometimes need redirection, whereas internally created ExternalReferences are just stored as they are. In addition, by removing the isolate from the signature of the public constructors, they suddenly exactly matched the interal constructor. * Replace all uses of the public constructors with ExternalReference::Create(). * Remove the isolate from all call sites where necessary. This is a step towards making WebAssembly compilation independent of the isolate. R=mstarzinger@chromium.org Bug: v8:7570 Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng Change-Id: I750c162f5d58ed32e866722b0db920f8b9bd8057 Reviewed-on: https://chromium-review.googlesource.com/1026673Reviewed-by:
Michael Starzinger <mstarzinger@chromium.org> Commit-Queue: Andreas Haas <ahaas@chromium.org> Cr-Commit-Position: refs/heads/master@{#52777}
-
- 24 Apr, 2018 2 commits
-
-
Andreas Haas authored
This reverts commit 44ea425a. Reason for revert: https://ci.chromium.org/buildbot/client.v8.ports/V8%20Arm%20-%20debug%20builder/13575 Original change's description: > [refactoring] Remove the isolate from signatures of ExternalReferences > > In this CL I remove the isolate from signatures of ExternalReference > accessor functions where the isolate is not used. The uses of the > isolate were already removed in previous CLs. > > Changes: > * I split the ExternalReference list in external-reference.h into > those which need the isolate for initialization and those which do not. > > * I removed the public constructors and replaced them by > ExternalReference::Create(). The reason is to separate external > creation more clearly from internal creation, because externally > created ExternalReferences sometimes need redirection, whereas > internally created ExternalReferences are just stored as they are. > In addition, by removing the isolate from the signature of the > public constructors, they suddenly exactly matched the interal > constructor. > > * Replace all uses of the public constructors with > ExternalReference::Create(). > > * Remove the isolate from all call sites where necessary. > > > This is a step towards making WebAssembly compilation independent of > the isolate. > > Bug: v8:7570 > R=mstarzinger@chromium.org > > Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng > Change-Id: I14f511fc6acc50ab2d6a6641299f5ddbeabef0da > Reviewed-on: https://chromium-review.googlesource.com/1018982 > Commit-Queue: Andreas Haas <ahaas@chromium.org> > Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> > Cr-Commit-Position: refs/heads/master@{#52768} TBR=mstarzinger@chromium.org,ahaas@chromium.org Change-Id: I7c0d8d420f815cede23d550dee8942ac4d7791cc No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: v8:7570 Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng Reviewed-on: https://chromium-review.googlesource.com/1026570Reviewed-by:
Andreas Haas <ahaas@chromium.org> Commit-Queue: Andreas Haas <ahaas@chromium.org> Cr-Commit-Position: refs/heads/master@{#52769}
-
Andreas Haas authored
In this CL I remove the isolate from signatures of ExternalReference accessor functions where the isolate is not used. The uses of the isolate were already removed in previous CLs. Changes: * I split the ExternalReference list in external-reference.h into those which need the isolate for initialization and those which do not. * I removed the public constructors and replaced them by ExternalReference::Create(). The reason is to separate external creation more clearly from internal creation, because externally created ExternalReferences sometimes need redirection, whereas internally created ExternalReferences are just stored as they are. In addition, by removing the isolate from the signature of the public constructors, they suddenly exactly matched the interal constructor. * Replace all uses of the public constructors with ExternalReference::Create(). * Remove the isolate from all call sites where necessary. This is a step towards making WebAssembly compilation independent of the isolate. Bug: v8:7570 R=mstarzinger@chromium.org Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng Change-Id: I14f511fc6acc50ab2d6a6641299f5ddbeabef0da Reviewed-on: https://chromium-review.googlesource.com/1018982 Commit-Queue: Andreas Haas <ahaas@chromium.org> Reviewed-by:
Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#52768}
-
- 09 Apr, 2018 1 commit
-
-
Jakob Kummerow authored
There is no good reason to have the meat of most objects' initialization logic in heap.cc, all wrapped by the CALL_HEAP_FUNCTION macro. Instead, this CL changes the protocol between Heap and Factory to be AllocateRaw, and all object initialization work after (possibly retried) successful raw allocation happens in the Factory. This saves about 20KB of binary size on x64. Original review: https://chromium-review.googlesource.com/c/v8/v8/+/959533 Originally landed as r52416 / f9a2e24b Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng Change-Id: Id072cbe6b3ed30afd339c7e502844b99ca12a647 Reviewed-on: https://chromium-review.googlesource.com/1000540 Commit-Queue: Jakob Kummerow <jkummerow@chromium.org> Reviewed-by:
Hannes Payer <hpayer@chromium.org> Reviewed-by:
Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#52492}
-
- 06 Apr, 2018 2 commits
-
-
Michael Achenbach authored
This reverts commit f9a2e24b. Reason for revert: gc stress failures not all fixed by follow up. Original change's description: > [cleanup] Refactor the Factory > > There is no good reason to have the meat of most objects' initialization > logic in heap.cc, all wrapped by the CALL_HEAP_FUNCTION macro. Instead, > this CL changes the protocol between Heap and Factory to be AllocateRaw, > and all object initialization work after (possibly retried) successful > raw allocation happens in the Factory. > > This saves about 20KB of binary size on x64. > > Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng > Change-Id: Icbfdc4266d7be8b48d2fe085f03411743dc6a0ca > Reviewed-on: https://chromium-review.googlesource.com/959533 > Commit-Queue: Jakob Kummerow <jkummerow@chromium.org> > Reviewed-by: Hannes Payer <hpayer@chromium.org> > Reviewed-by: Yang Guo <yangguo@chromium.org> > Cr-Commit-Position: refs/heads/master@{#52416} TBR=jkummerow@chromium.org,yangguo@chromium.org,mstarzinger@chromium.org,hpayer@chromium.org Change-Id: Idbbc53478742f3e9525eee83342afc6aedae122f No-Presubmit: true No-Tree-Checks: true No-Try: true Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng Reviewed-on: https://chromium-review.googlesource.com/999414Reviewed-by:
Michael Achenbach <machenbach@chromium.org> Commit-Queue: Michael Achenbach <machenbach@chromium.org> Cr-Commit-Position: refs/heads/master@{#52420}
-
Jakob Kummerow authored
There is no good reason to have the meat of most objects' initialization logic in heap.cc, all wrapped by the CALL_HEAP_FUNCTION macro. Instead, this CL changes the protocol between Heap and Factory to be AllocateRaw, and all object initialization work after (possibly retried) successful raw allocation happens in the Factory. This saves about 20KB of binary size on x64. Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng Change-Id: Icbfdc4266d7be8b48d2fe085f03411743dc6a0ca Reviewed-on: https://chromium-review.googlesource.com/959533 Commit-Queue: Jakob Kummerow <jkummerow@chromium.org> Reviewed-by:
Hannes Payer <hpayer@chromium.org> Reviewed-by:
Yang Guo <yangguo@chromium.org> Cr-Commit-Position: refs/heads/master@{#52416}
-
- 09 Mar, 2018 1 commit
-
-
jgruber authored
The macro list avoids duplication in external-reference-table and will allow us to statically determine the size of the table in a follow-up. TBR=mlippautz@chromium.org Bug: v8:6666 Change-Id: I06bb2e8c25970b3c1047dafd6c63d7ca291fe37e Reviewed-on: https://chromium-review.googlesource.com/956187 Commit-Queue: Jakob Gruber <jgruber@chromium.org> Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Reviewed-by:
Sathya Gunasekaran <gsathya@chromium.org> Cr-Commit-Position: refs/heads/master@{#51850}
-
- 05 Mar, 2018 2 commits
-
-
Sigurd Schneider authored
Bug: v8:7517, v8:7310 Change-Id: Ic9a1ac8f4a928e1d5d8f807a0875c7314a7777fb Reviewed-on: https://chromium-review.googlesource.com/946095 Commit-Queue: Sigurd Schneider <sigurds@chromium.org> Reviewed-by:
Benedikt Meurer <bmeurer@chromium.org> Cr-Commit-Position: refs/heads/master@{#51735}
-
Sigurd Schneider authored
This also introduces FrameStateInfoOf helper. Bug: v8:7517, v8:7310 Change-Id: If2dd1257fb9384fe957a980077a65154cc014d3b Reviewed-on: https://chromium-review.googlesource.com/946009 Commit-Queue: Sigurd Schneider <sigurds@chromium.org> Reviewed-by:
Benedikt Meurer <bmeurer@chromium.org> Cr-Commit-Position: refs/heads/master@{#51718}
-
- 09 Oct, 2017 1 commit
-
-
Michael Starzinger authored
R=marja@chromium.org Change-Id: I93a366caded175256abd7966c3c157191a2b7de2 Reviewed-on: https://chromium-review.googlesource.com/690455 Commit-Queue: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by:
Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#48370}
-
- 07 Feb, 2017 1 commit
-
-
ishell@chromium.org authored
... and TypeFeedbackMetadata to FeedbackMetadata. BUG= Change-Id: I2556d1c2a8f37b8cf3d532cc98d973b6dc7e9e6c Reviewed-on: https://chromium-review.googlesource.com/439244 Commit-Queue: Igor Sheludko <ishell@chromium.org> Reviewed-by:
Michael Starzinger <mstarzinger@chromium.org> Reviewed-by:
Michael Stanton <mvstanton@chromium.org> Reviewed-by:
Jaroslav Sevcik <jarin@chromium.org> Reviewed-by:
Yang Guo <yangguo@chromium.org> Reviewed-by:
Hannes Payer <hpayer@chromium.org> Cr-Commit-Position: refs/heads/master@{#42999}
-
- 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 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}
-
- 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 2 commits
-
-
mstarzinger authored
R=jochen@chromium.org Review URL: https://codereview.chromium.org/1417163004 Cr-Commit-Position: refs/heads/master@{#31632}
-
mstarzinger authored
R=jochen@chromium.org Review URL: https://codereview.chromium.org/1408283006 Cr-Commit-Position: refs/heads/master@{#31630}
-
- 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}
-
- 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}
-
- 30 Jun, 2015 1 commit
-
-
bmeurer authored
This optimization never triggers currently, and is inherently native context dependent for no real reason (for example it will not properly detect those constructors in the case of cross native context inlining), plus it is slow and awkward. In case we really need this functionality at some point, we should find a way to make it work with the builtin function id mechanism that is already in place to match other builtins. R=jarin@chromium.org,rossberg@chromium.org Review URL: https://codereview.chromium.org/1221683006 Cr-Commit-Position: refs/heads/master@{#29365}
-
- 24 Jun, 2015 1 commit
-
-
danno authored
- Thread Type::FunctionType through stubs and the TF pipeline. - Augment Typer to decorate parameter nodes with types from a Type::FunctionType associated with interface descriptors. - Factor interface descriptors into platform-specific and platform-independent components so that all descriptors share a common Type::FunctionType for all platforms. Review URL: https://codereview.chromium.org/1197703002 Cr-Commit-Position: refs/heads/master@{#29248}
-
- 12 Jun, 2015 1 commit
-
-
bmeurer authored
Up until now we used int32_t for NodeId, but that was not ideal because negative values are invalid for NodeId and we use it as an array index for example in the NodeMarker class, where C++ compilers on x64 have to generate code that does proper sign extension for the indices, which is completely unnecessary. R=svenpanne@chromium.org Review URL: https://codereview.chromium.org/1178403004 Cr-Commit-Position: refs/heads/master@{#28997}
-
- 26 May, 2015 1 commit
-
-
bmeurer authored
This simplifies the handling of the End node. Based on this CL we will finally fix terminating every loop from the beginning (via Terminate nodes) and fix inlining of Throw, Deoptimize and Terminate. R=mstarzinger@chromium.org Review URL: https://codereview.chromium.org/1157023002 Cr-Commit-Position: refs/heads/master@{#28620}
-
- 30 Jan, 2015 3 commits
-
-
bmeurer authored
R=svenpanne@chromium.org Review URL: https://codereview.chromium.org/877753007 Cr-Commit-Position: refs/heads/master@{#26346}
-
Benedikt Meurer authored
This reverts commit 6a4c0a3b and commit 0deaa4b6 for breaking GCC bots. TBR=svenpanne@chromium.org Review URL: https://codereview.chromium.org/893533003 Cr-Commit-Position: refs/heads/master@{#26342}
-
bmeurer authored
R=svenpanne@chromium.org Review URL: https://codereview.chromium.org/888613002 Cr-Commit-Position: refs/heads/master@{#26340}
-
- 29 Jan, 2015 1 commit
-
-
bmeurer authored
R=svenpanne@chromium.org Review URL: https://codereview.chromium.org/883613006 Cr-Commit-Position: refs/heads/master@{#26316}
-
- 23 Jan, 2015 1 commit
-
-
danno authored
Along the way: - Thread isolate parameter explicitly through code that used to rely on getting it from the zone. - Canonicalize the parameter position of isolate and zone for affected code - Change Hydrogen New<> instruction templates to automatically pass isolate R=mstarzinger@chromium.org LOG=N Review URL: https://codereview.chromium.org/868883002 Cr-Commit-Position: refs/heads/master@{#26252}
-
- 21 Jan, 2015 1 commit
-
-
bmeurer authored
Use std::numeric_limits<double>::quiet_NaN() and std::numeric_limits<float>::quiet_NaN() instead. Review URL: https://codereview.chromium.org/864803002 Cr-Commit-Position: refs/heads/master@{#26195}
-
- 20 Dec, 2014 1 commit
-
-
machenbach authored
Revert of Remove obsolete V8_INFINITY macro. (patchset #3 id:40001 of https://codereview.chromium.org/798413003/) Reason for revert: Speculative revert. This seems to block the current roll: https://codereview.chromium.org/819653003/ I retried several times, also with a new roll. The error is internal - but that doesn't make much of a difference. Original issue's description: > Remove obsolete V8_INFINITY macro. > > Use std::numeric_limits consistently. > > R=svenpanne@chromium.org > > Committed: https://crrev.com/31c66e2d53569c4e229d55483d28208491e73612 > Cr-Commit-Position: refs/heads/master@{#25897} TBR=svenpanne@chromium.org,bmeurer@chromium.org NOTREECHECKS=true NOTRY=true Review URL: https://codereview.chromium.org/813813003 Cr-Commit-Position: refs/heads/master@{#25912}
-