- 13 Feb, 2018 21 commits
-
-
Camillo Bruni authored
FATAL(...) avoid creating literal strings for line number in release mode. Bug: v8:7310 Change-Id: I6a3e329adce36b0efcc240068f6a241d1cca4b6f Reviewed-on: https://chromium-review.googlesource.com/915066Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by: Andreas Haas <ahaas@chromium.org> Commit-Queue: Camillo Bruni <cbruni@chromium.org> Cr-Commit-Position: refs/heads/master@{#51277}
-
Junliang Yan authored
This reverts commit cee362af. Reason for revert: forget to upload latest version Original change's description: > PPC/s390: [turbofan] Masking/poisoning in codegen (optimized code, x64) > > Port 8f489e73 > > Original Commit Message: > > This introduces masking of loads with speculation bit during code generation. > At the moment, this is done only for x64 optimized code, under the > --branch-load-poisoning flag. > > Overview of changes: > - new register configuration configuration with one register reserved for > the speculation poison/mask (kSpeculationPoisonRegister). > - in codegen, we introduce an update to the poison register at the starts > of all successors of branches (and deopts) that are marked as safety > branches (deopts). > - in memory optimizer, we lower all field and element loads to PoisonedLoads. > - poisoned loads are then masked in codegen with the poison register. > * only integer loads are masked at the moment. > > R=mvstanton@chromium.org, joransiu@ca.ibm.com, michael_dawson@ca.ibm.com > BUG= > LOG=N > > Change-Id: I7decc16bbadf87a8c8b178278eb79a9b783f79e1 > Reviewed-on: https://chromium-review.googlesource.com/916744 > Reviewed-by: Joran Siu <joransiu@ca.ibm.com> > Commit-Queue: Junliang Yan <jyan@ca.ibm.com> > Cr-Commit-Position: refs/heads/master@{#51275} TBR=mvstanton@chromium.org,michael_dawson@ca.ibm.com,jyan@ca.ibm.com,joransiu@ca.ibm.com Change-Id: I7e56cdcd99b3c6004803b4502ec1054e89c1e212 No-Presubmit: true No-Tree-Checks: true No-Try: true Reviewed-on: https://chromium-review.googlesource.com/916864Reviewed-by: Junliang Yan <jyan@ca.ibm.com> Commit-Queue: Junliang Yan <jyan@ca.ibm.com> Cr-Commit-Position: refs/heads/master@{#51276}
-
Junliang Yan authored
Port 8f489e73 Original Commit Message: This introduces masking of loads with speculation bit during code generation. At the moment, this is done only for x64 optimized code, under the --branch-load-poisoning flag. Overview of changes: - new register configuration configuration with one register reserved for the speculation poison/mask (kSpeculationPoisonRegister). - in codegen, we introduce an update to the poison register at the starts of all successors of branches (and deopts) that are marked as safety branches (deopts). - in memory optimizer, we lower all field and element loads to PoisonedLoads. - poisoned loads are then masked in codegen with the poison register. * only integer loads are masked at the moment. R=mvstanton@chromium.org, joransiu@ca.ibm.com, michael_dawson@ca.ibm.com BUG= LOG=N Change-Id: I7decc16bbadf87a8c8b178278eb79a9b783f79e1 Reviewed-on: https://chromium-review.googlesource.com/916744Reviewed-by: Joran Siu <joransiu@ca.ibm.com> Commit-Queue: Junliang Yan <jyan@ca.ibm.com> Cr-Commit-Position: refs/heads/master@{#51275}
-
Andreas Haas authored
At the moment the flag is set too late, it is possible that the GC still tries to post tasks in Isolate::Deinit when the isolate is already disconnected from the platform, see the referenced bug. R=ulan@chromium.org Bug: chromium:810739 Change-Id: Ibcd226cb44cc903f2a46e7cccf682b3938c9d408 Reviewed-on: https://chromium-review.googlesource.com/915942Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Commit-Queue: Andreas Haas <ahaas@chromium.org> Cr-Commit-Position: refs/heads/master@{#51274}
-
Junliang Yan authored
Port a021b6c4 Original Commit Message: Moves generation of speculation poison to be based on the PC target vs the actual PC being executed. The speculation poison is generated in the prologue of the generated code if CompilationInfo::kGenerateSpeculationPoison is set. The result is stored in a known register, which can then be read using the SpeculationPoison machine node. Currently we need to ensure the SpeculationPoison node is scheduled right after the code prologue so that the poison register doesn't get clobbered. This is currently not verified, however it's only use is in RawMachineAssembler where it is manually scheduled early. The Ignition bytecode handlers are updated to use this speculation poison rather than one generated by comparing the target bytecode. R=rmcilroy@chromium.org, joransiu@ca.ibm.com, michael_dawson@ca.ibm.com BUG=chromium:798964 LOG=N Change-Id: I4b9a1b0865b6164171cf83f0e45c36c69ac08a18 Reviewed-on: https://chromium-review.googlesource.com/914848Reviewed-by: Joran Siu <joransiu@ca.ibm.com> Commit-Queue: Junliang Yan <jyan@ca.ibm.com> Cr-Commit-Position: refs/heads/master@{#51273}
-
Mike Stanton authored
This introduces masking of loads with speculation bit during code generation. At the moment, this is done only for x64 optimized code, under the --branch-load-poisoning flag. Overview of changes: - new register configuration configuration with one register reserved for the speculation poison/mask (kSpeculationPoisonRegister). - in codegen, we introduce an update to the poison register at the starts of all successors of branches (and deopts) that are marked as safety branches (deopts). - in memory optimizer, we lower all field and element loads to PoisonedLoads. - poisoned loads are then masked in codegen with the poison register. * only integer loads are masked at the moment. Bug: chromium:798964 Change-Id: Ie51fdbde578fc289dff029794f3cfe8eaf33e1ef Reviewed-on: https://chromium-review.googlesource.com/901625 Commit-Queue: Michael Stanton <mvstanton@chromium.org> Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> Cr-Commit-Position: refs/heads/master@{#51272}
-
Michael Starzinger authored
R=mvstanton@chromium.org No-Presubmit: true No-Tree-Checks: true No-Try: true Change-Id: I6175fd4c4e2999667ba04c89df5cd3f2b380ae0a Reviewed-on: https://chromium-review.googlesource.com/916263Reviewed-by: Michael Stanton <mvstanton@chromium.org> Commit-Queue: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#51271}
-
Michael Starzinger authored
This decouples the checking of the {kJavaScriptCallCodeStartRegister} from the deoptimization checks. We now rely more heavily on the above register and should check its validity more broadly. Note that there also is a bug fix for the ARM port contained in this change. R=mvstanton@chromium.org Change-Id: I27d8b72cb2b36a85dae4bbbf35e4dbcf150eac01 Reviewed-on: https://chromium-review.googlesource.com/916242 Commit-Queue: Michael Stanton <mvstanton@chromium.org> Reviewed-by: Michael Stanton <mvstanton@chromium.org> Cr-Commit-Position: refs/heads/master@{#51270}
-
Michael Starzinger authored
Now that instruction cache flushing is process-wide and no longer bound to a specific {Isolate}, we can also make setters on the {RelocInfo} structure equally independent of the {Isolate} and remove the respective parameter everywhere. R=ahaas@chromium.org Change-Id: I7b21f6f79d0d6cf73424019b9e808c3ec76de08e Reviewed-on: https://chromium-review.googlesource.com/915922Reviewed-by: Andreas Haas <ahaas@chromium.org> Commit-Queue: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#51269}
-
sreten.kovacevic authored
Change prototypes of conditional jump and set instructions, change their implementation accordingly and port these instructions to MIPS. Bug: v8:6600 Change-Id: I8e2c9c874f2fde9a1c1b5a34eaa9e72475e69bc5 Reviewed-on: https://chromium-review.googlesource.com/913252Reviewed-by: Ivica Bogosavljevic <ivica.bogosavljevic@mips.com> Reviewed-by: Clemens Hammacher <clemensh@chromium.org> Commit-Queue: Sreten Kovacevic <sreten.kovacevic@mips.com> Cr-Commit-Position: refs/heads/master@{#51268}
-
Peter Marshall authored
We don't need to pay the cost of going to JS to simply stamp out a new object. Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng Change-Id: I8942771ff9c19dff1908243fd6d3bd701d3fb5a3 Reviewed-on: https://chromium-review.googlesource.com/897803 Commit-Queue: Peter Marshall <petermarshall@chromium.org> Reviewed-by: Michael Lippautz <mlippautz@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#51267}
-
Michael Starzinger authored
R=clemensh@chromium.org Change-Id: Ife4b31e5484314e3e9d51344c446fae4952bbbbf Reviewed-on: https://chromium-review.googlesource.com/913616Reviewed-by: Clemens Hammacher <clemensh@chromium.org> Commit-Queue: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#51266}
-
Sigurd Schneider authored
This is a reland of 6d5b54df82e27a82811a836dcdbbfe26829f0e6d Original change's description: > [cleanup] Harden the SubString CSA/Runtime implementations. > > Remove the self-healing for invalid parameters in the > CodeStubAssembler::SubString helper and the %SubString runtime function, > which is used as a fallback for the CodeStubAssembler implementation. > All call sites must do appropriate parameter validation anyways now that > the self-hosted JavaScript builtins using these helpers are gone, and we > have proper contracts with the uses. > > Also remove the context parameter from the CodeStubAssembler::SubString > method, which is unnecessary, since this can no longer throw an > exception. > > Bug: v8:5269, v8:6936, v8:7109, v8:7137 > Change-Id: I19d93bad5f41faa0561c4561a48f78fcba99a549 > Reviewed-on: https://chromium-review.googlesource.com/795720 > Reviewed-by: Jakob Gruber <jgruber@chromium.org> > Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> > Cr-Commit-Position: refs/heads/master@{#49702} Bug: v8:5269, v8:6936, v8:7109, v8:7137 Change-Id: I5e84998a2dd3990d7981505b401ffc770e0b7ac5 Reviewed-on: https://chromium-review.googlesource.com/913130Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> Commit-Queue: Sigurd Schneider <sigurds@chromium.org> Cr-Commit-Position: refs/heads/master@{#51265}
-
Georg Neis authored
Change-Id: I835e6c7b5520b5ab5ad796e25a197e5b43cb9e58 Reviewed-on: https://chromium-review.googlesource.com/913569 Commit-Queue: Georg Neis <neis@chromium.org> Reviewed-by: Michael Stanton <mvstanton@chromium.org> Cr-Commit-Position: refs/heads/master@{#51264}
-
Clemens Hammacher authored
This CL adds support for f64.const, f64.add, f64.sub and f64.mul. R=ahaas@chromium.org Bug: v8:6600 Change-Id: I7374ede800db83303c8fa647a183fdda53a151cd Reviewed-on: https://chromium-review.googlesource.com/913613Reviewed-by: Andreas Haas <ahaas@chromium.org> Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Cr-Commit-Position: refs/heads/master@{#51263}
-
v8-autoroll authored
Rolling v8/build: https://chromium.googlesource.com/chromium/src/build/+log/792040c..1ae61ca Rolling v8/buildtools: https://chromium.googlesource.com/chromium/buildtools/+log/2637e7e..a09e064 Rolling v8/third_party/catapult: https://chromium.googlesource.com/catapult/+log/c60b98d..e7298f3 TBR=machenbach@chromium.org,hablich@chromium.org,sergiyb@chromium.org Change-Id: I267b24e59799c9e18735851336d7787252dc59e2 Reviewed-on: https://chromium-review.googlesource.com/915702Reviewed-by: v8 autoroll <v8-autoroll@chromium.org> Commit-Queue: v8 autoroll <v8-autoroll@chromium.org> Cr-Commit-Position: refs/heads/master@{#51262}
-
Benedikt Meurer authored
The idea here is that in case the `thenable` is a JSPromise and `then` is the initial `Promise.prototype.then` method, and the @@species lookup chain is intact, we can skip creating the temporary promise and the closures (with the shared context), and instead directly call into our PerformPromiseThen. This is sound since - given above mentioned conditions - our short-cut PerformPromiseThen(thenable, undefined, undefined, promise_to_resolve) is not observably different from the actual resolve, reject = CreateResolvingFunctions(promise_to_resolve) result_capability = NewPromiseCapability(%Promise%) PerformPromiseThen(thenable, resolve, reject, result_capability) except through PromiseHooks (and potentially via the async stack traces). So we disable the fast-path if either promise hooks are enabled or the debugger is active for now. This improves the performance on the wikipedia benchmark by 20-25% and the bluebird-doxbee benchmark by around 20%. Bug: v8:7253 Change-Id: I23c92ad365c2b71d65057573f2d8febe2afe00b0 Reviewed-on: https://chromium-review.googlesource.com/911800 Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org> Cr-Commit-Position: refs/heads/master@{#51261}
-
Benedikt Meurer authored
This introduces dedicated builtins - FulfillPromise, - RejectPromise, and - ResolvePromise, which perform the corresponding operations from the language specification, and removes the redundant entry points and the excessive inlining of these operations into other builtins. We also add the same logic on the C++ side, so that we don't need to go into JavaScript land when resolving/rejecting from the API. The C++ side has a complete implementation, including full support for the debugger and the current PromiseHook machinery. This is to avoid constantly crossing the boundary for those cases, and to also simplify the CSA side (and soon the TurboFan side), where we only do the fast-path and bail out to the runtime for the general handling. On top of this we introduce %_RejectPromise and %_ResolvePromise, which are entry points used by the bytecode and parser desugarings for async functions, and also used by the V8 Extras API. Thanks to this we can uniformly optimize these in TurboFan, where we have corresponding operators JSRejectPromise and JSResolvePromise, which currently just call into the builtins, but middle-term can be further optimized, i.e. to skip the "then" lookup for JSResolvePromise when we know something about the resolution. In TurboFan we can also already inline the default PromiseCapability [[Reject]] and [[Resolve]] functions, although this is not as effective as it can be right now, until we have inlining support for the Promise constructor (being worked on by petermarshall@ right now) and/or SFI based CALL_IC feedback. Overall this change is meant as a refactoring without significant performance impact anywhere; it seems to improve performance of simple async functions a bit, but otherwise is neutral. Bug: v8:7253 Change-Id: Id0b979f9b2843560e38cd8df4b02627dad4b6d8c Reviewed-on: https://chromium-review.googlesource.com/911632Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org> Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Cr-Commit-Position: refs/heads/master@{#51260}
-
Sergiy Byelozyorov authored
This information is useful to know whom to assign bugs to when these tests are crashing on our infrastructure. R=petermarshall@chromium.org No-Try: true Change-Id: Ia165e0236602cae73e144011537d642e3535fa6b Reviewed-on: https://chromium-review.googlesource.com/908563 Commit-Queue: Sergiy Byelozyorov <sergiyb@chromium.org> Reviewed-by: Peter Marshall <petermarshall@chromium.org> Cr-Commit-Position: refs/heads/master@{#51259}
-
Sergiy Byelozyorov authored
R=sergiyb@google.com No-Try: true Bug: chromium:616879 Change-Id: If52f419c7447c88313526fceed10e7dd2e89b10c Reviewed-on: https://chromium-review.googlesource.com/913948 Commit-Queue: Sergiy Byelozyorov <sergiyb@chromium.org> Reviewed-by: Sergiy Byelozyorov <sergiyb@chromium.org> Cr-Commit-Position: refs/heads/master@{#51258}
-
Sergiy Byelozyorov authored
TBR=machenbach@chromium.org No-Try: true Bug: chromium:616879 Change-Id: I49d3f12216cdc2d26761e8f82fef18512d8eb6fd Reviewed-on: https://chromium-review.googlesource.com/915141 Commit-Queue: Sergiy Byelozyorov <sergiyb@chromium.org> Reviewed-by: Sergiy Byelozyorov <sergiyb@chromium.org> Cr-Commit-Position: refs/heads/master@{#51257}
-
- 12 Feb, 2018 19 commits
-
-
Wez authored
The next Fuchsia SDK roll changes the signature and types associated with the zx_thread_read_state() API, so we temporarily need backward- compatibility shims while we roll the SDK/Chromium/V8. Bug: chromium:707030 Change-Id: I419a65bbb631a1ef0d7d5044b07d4cbbac08970f Reviewed-on: https://chromium-review.googlesource.com/914695 Commit-Queue: Wez <wez@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Cr-Commit-Position: refs/heads/master@{#51256}
-
Camillo Bruni authored
Bug: chromium:808192 Change-Id: I80136d291d5c21c311903bffc96d86d109f5cdc9 Reviewed-on: https://chromium-review.googlesource.com/902103 Commit-Queue: Jakob Kummerow <jkummerow@chromium.org> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> Cr-Commit-Position: refs/heads/master@{#51255}
-
Adam Klein authored
This pretenuring was added in https://codereview.chromium.org/5220007, back when it was necessary in order to allow use of the closure as a "constant function" property. This should no longer be the case, and the pretenuring causes some unfortunate downstream effects. This patch removes the parser's setting of this bit. If it doesn't cause regressions on the perf bots, followup CLs will remove the rest of the support for this feature. Bug: v8:7442 Change-Id: I27c43dd4293ce5de921be6c78571e712778d138a Reviewed-on: https://chromium-review.googlesource.com/914610Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org> Commit-Queue: Adam Klein <adamk@chromium.org> Cr-Commit-Position: refs/heads/master@{#51254}
-
Franziska Hinkelmann authored
Change-Id: Ic0e513e61e3bd1a8ac8f06a1f81c27d35a7d29af Reviewed-on: https://chromium-review.googlesource.com/911249Reviewed-by: Andreas Haas <ahaas@chromium.org> Commit-Queue: Franziska Hinkelmann <franzih@chromium.org> Cr-Commit-Position: refs/heads/master@{#51253}
-
Ben L. Titzer authored
R=bradnelson@chromium.org Bug: chromium:810973 Change-Id: I818c17ef03b27df72976048b1873fc3f3a368900 Reviewed-on: https://chromium-review.googlesource.com/914330Reviewed-by: Brad Nelson <bradnelson@chromium.org> Commit-Queue: Ben Titzer <titzer@chromium.org> Cr-Commit-Position: refs/heads/master@{#51252}
-
Mathias Bynens authored
Intent to ship: https://groups.google.com/d/msg/v8-users/f6t2VJha_3o/fzJjpahaCgAJ Bug: v8:6530 Change-Id: I380ac947df9fe6ca7deb3315540388fc923810ea Reviewed-on: https://chromium-review.googlesource.com/912869Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> Commit-Queue: Mathias Bynens <mathias@chromium.org> Cr-Commit-Position: refs/heads/master@{#51251}
-
Camillo Bruni authored
Most of the users of these api methods manually ensure that the returned values are Strings. With an additional flag we can easily ensure that already in V8 and avoid needless api roundtrips. Bug: v8:7358 Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng Change-Id: I62165d44084abc9f07f5bdaace5105847edca60a Reviewed-on: https://chromium-review.googlesource.com/901248Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Franziska Hinkelmann <franzih@chromium.org> Commit-Queue: Camillo Bruni <cbruni@chromium.org> Cr-Commit-Position: refs/heads/master@{#51250}
-
Gabriel Charette authored
This is a follow-up to https://chromium-review.googlesource.com/904662 as I forgot this callsite there. The perf tests still haven't recovered from decreasing the worker count by 1 to account for main thread (crbug.com/809961) and I assume this line is at fault. If this is correct, it also indicates ConcurrentMarking as a great area to focus since a single extra worker appears to be making a significant difference. R=mlippautz@chromium.org Bug: chromium:809961, chromium:808028 Change-Id: I9df933a4193fb25ea4e857f589e2164c8a2859b4 Reviewed-on: https://chromium-review.googlesource.com/911670Reviewed-by: Michael Lippautz <mlippautz@chromium.org> Commit-Queue: Gabriel Charette <gab@chromium.org> Cr-Commit-Position: refs/heads/master@{#51249}
-
Caitlin Potter authored
Implements the change outlined in https://github.com/tc39/ecma262/pull/890, which has been ratified and pulled into the specification. In particular, template callsite objects are no longer kept in a global, eternal Map, but are instead associated with their callsite, which can be collected. This prevents a memory leak incurred by TaggedTemplate calls. Changes, summarized: - Remove the TemplateMap and TemplateMapShape objects, instead caching template objects in the feedback vector. - Remove the `hash` member of TemplateObjectDescriptor, and the Equals method (used by TemplateMap) - Add a new FeedbackSlotKind (kTemplateObject), which behaves similarly to FeedbackSlotKind::kLiteral, but prevents eval caching. This ensures that a new feedback vector is always created for eval() containing tagged templates, even when the CompilationCache is used. - GetTemplateObject bytecode now takes a feedback index, and only calls into the runtime if the feedback is Smi::kZero (uninitialized). BUG=v8:3230, v8:2891 R=littledan@chromium.org, yangguo@chromium.org, bmeurer@chromium.org, rmcilroy@chromium.org Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng Change-Id: I7827bc148d3d93e2b056ebf63dd624da196ad423 Reviewed-on: https://chromium-review.googlesource.com/624564 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#51248}
-
Junliang Yan authored
some time the output of these two could be the same if machine is fast enough. Change-Id: I1d9c0191657abae3d053517d45059065df2d44dc Reviewed-on: https://chromium-review.googlesource.com/911873Reviewed-by: Georg Neis <neis@chromium.org> Commit-Queue: Junliang Yan <jyan@ca.ibm.com> Cr-Commit-Position: refs/heads/master@{#51247}
-
Sergiy Byelozyorov authored
TBR=sergiyb@chromium.org No-Try: true Bug: chromium:616879 Change-Id: I9570a07f3a1626ca981a22cca2fb1da45e82e738 Reviewed-on: https://chromium-review.googlesource.com/913333 Commit-Queue: Sergiy Byelozyorov <sergiyb@chromium.org> Reviewed-by: Sergiy Byelozyorov <sergiyb@chromium.org> Cr-Commit-Position: refs/heads/master@{#51246}
-
Yang Guo authored
R=jgruber@chromium.org Bug: v8:5510 Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng Change-Id: Ic0ba012ed7ff66f034c5a54554b2ab36d1d70d2c Reviewed-on: https://chromium-review.googlesource.com/911110Reviewed-by: Jakob Gruber <jgruber@chromium.org> Commit-Queue: Yang Guo <yangguo@chromium.org> Commit-Queue: ปอ คับ <misspor061853@gmail.com> Cr-Commit-Position: refs/heads/master@{#51245}
-
Andreas Haas authored
According to the spec, if an imported function gets exported, the exported function has to be identical to to imported function. With this CL we initialize the list of potential js_wrappers_ with all wasm function we imported. Therefore no new wrappers are generated for these functions. R=clemensh@chromium.org Bug: v8:7364 Change-Id: Ibcd47d8fcc4c2fb5740d57ea547fbd01c2a4e80a Reviewed-on: https://chromium-review.googlesource.com/901626 Commit-Queue: Andreas Haas <ahaas@chromium.org> Reviewed-by: Clemens Hammacher <clemensh@chromium.org> Cr-Commit-Position: refs/heads/master@{#51244}
-
Michael Achenbach authored
This cleans up mb_config.pyl and strips it from: - remaining gyp_defines entries and other mention of gyp - all redundant 'gn_' prefixes and configs These changes are possible after https://crrev.com/c/911073 Bug: chromium:772804 Change-Id: I702405cc97ef2cc14b2c2cc5870c8315dde8342a Reviewed-on: https://chromium-review.googlesource.com/912830Reviewed-by: Sergiy Byelozyorov <sergiyb@chromium.org> Commit-Queue: Michael Achenbach <machenbach@chromium.org> Cr-Commit-Position: refs/heads/master@{#51243}
-
Clemens Hammacher authored
Currently, the LiftoffCompiler can bail out on unsupported instructions, but the LiftoffAssembler can not. This makes it difficult to iteratively implement the platform specific part of the assembler. With this CL, also the assembler can bail out if an unimplemented assembler method is called. This allows to test already implemented methods. R=ahaas@chromium.org CC=sreten.kovacevic@mips.com Bug: v8:6600 Change-Id: Ieb7abc2188266bb93c40fe55fd6ee0e5b1e0d220 Reviewed-on: https://chromium-review.googlesource.com/909390 Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Reviewed-by: Andreas Haas <ahaas@chromium.org> Cr-Commit-Position: refs/heads/master@{#51242}
-
Camillo Bruni authored
Change-Id: I48118d9e1240da7608ec33ab1855cdf3914d795a Bug: v8:7310 No-try: true Reviewed-on: https://chromium-review.googlesource.com/913489 Commit-Queue: Camillo Bruni <cbruni@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#51241}
-
Michael Achenbach authored
The corresponding gclient variables are set now via: https://crrev.com/c/913368 Bug: chromium:772804 Change-Id: I9c96bde3e6cc88d84a320c00d3316a91c48749f7 Reviewed-on: https://chromium-review.googlesource.com/913351Reviewed-by: Sergiy Byelozyorov <sergiyb@chromium.org> Commit-Queue: Michael Achenbach <machenbach@chromium.org> Cr-Commit-Position: refs/heads/master@{#51240}
-
Michael Achenbach authored
The test is slower on msan than its own anticipated runtime, which the test internally measures. TBR=danno@chromium.org NOTRY=true Bug: v8:7439 Change-Id: Iba08f589697bcf17b1f4d2cedb1313ff9a34c082 Reviewed-on: https://chromium-review.googlesource.com/913468Reviewed-by: Michael Achenbach <machenbach@chromium.org> Commit-Queue: Michael Achenbach <machenbach@chromium.org> Cr-Commit-Position: refs/heads/master@{#51239}
-
Stephan Herhut authored
When collecting stack frame information during a profiler tick event, we apply a filter on the instructions at the current pc to avoid collecting (wrong) stack frames while a frame is being setup/torn down. While this detection makes sense for compiled JavaScript code, it also filters out ticks in the C++ code base of v8. This change only applies the filter if the pc lies within a region that could potentially contain compiled JavaScript code. Change-Id: I8c8d8d70823abcdc2c5ae0ebf78a5198ec855a79 Reviewed-on: https://chromium-review.googlesource.com/912470Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> Commit-Queue: Stephan Herhut <herhut@chromium.org> Cr-Commit-Position: refs/heads/master@{#51238}
-