- 04 Dec, 2020 1 commit
-
-
Tobias Tebbi authored
Port String::Flatten to Torque (using a fast C call for the non-allocating part) and provide fast and easy access to sequential string data in Torque: GetStringData() flattens if necessary and computes slices that allow direct access. Applications: String.prototype.replaceAll, String.prototype.endsWith, and String.prototype.beginsWith now use GetStringData() and direct slice access instead of the slow StringCharCodeAt and they no longer bail out to the runtime for flattening. Drive-by changes: - Expose String instance type bits as bitfields and enums in Torque. - Fix method lookup in Torque to include superclass methods. - Use char8 and char16 types in more places. - Allow fast C calls with void return type. - Add Torque macros to create subslices. - Add no-GC scopes to runtime functions loading external string data. Bug: v8:7793 Change-Id: I763b9b24212770307c9b2fe9f070f21f65d68d58 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2565515 Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#71611}
-
- 19 Nov, 2020 1 commit
-
-
Tobias Tebbi authored
This uses the old trick from TypedArrays: a Smi-like all zero pattern plus an offset that actually contains a raw address to access off-heap data. Bug: v8:7793 Change-Id: Ia44448d4ff7e2dcaa02a2c5653f622fb93c3dd09 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2534817Reviewed-by: Nico Hartmann <nicohartmann@chromium.org> Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#71287}
-
- 13 Nov, 2020 1 commit
-
-
Ross McIlroy authored
Makes ExternalReference count as a subclass of RawPtrT to enable either to be passed to these functions as base argument. BUG=v8:6949,v8:11074 Change-Id: I126856815ff7cdc0612e3c3fcdfdd4938cc19bfa Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2534820 Auto-Submit: Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org> Reviewed-by: Santiago Aboy Solanes <solanes@chromium.org> Cr-Commit-Position: refs/heads/master@{#71171}
-
- 12 Nov, 2020 1 commit
-
-
Ross McIlroy authored
BUG=v8:6949,v8:11074 Change-Id: Ia5a52dcf42559d97eb6fd4a24f4abd3c40226017 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2531792 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Santiago Aboy Solanes <solanes@chromium.org> Cr-Commit-Position: refs/heads/master@{#71160}
-
- 11 Nov, 2020 5 commits
-
-
Ross McIlroy authored
They are never used, and can't really be TNodified since they are not a value output in any case. BUG=v8:6949,v8:11074 Change-Id: Id6f5807247c6fe53fb12dce9e2cfc66b5a046398 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2532305 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Auto-Submit: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Santiago Aboy Solanes <solanes@chromium.org> Cr-Commit-Position: refs/heads/master@{#71133}
-
Ross McIlroy authored
Splits the 64bit operation to a seperate function since there are different return types depending upon whether the architecture is 64-bit or 32-bit. BUG=v8:6949,v8:11074 Change-Id: If196cf658298ca0a1e5a13e1db812178307e7d12 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2531789 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Santiago Aboy Solanes <solanes@chromium.org> Cr-Commit-Position: refs/heads/master@{#71132}
-
Ross McIlroy authored
Splits the 64bit operation to a seperate function since there are different return types depending upon whether the architecture is 64-bit or 32-bit. BUG=v8:6949,v8:11074 Change-Id: I47c84a0104f71ec8865f12cbfa201f2f76cf08bc Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2529911 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Santiago Aboy Solanes <solanes@chromium.org> Cr-Commit-Position: refs/heads/master@{#71128}
-
Ross McIlroy authored
Splits the 64bit operations to a seperate function since there are different return types depending upon whether the architecture is 64-bit or 32-bit. BUG=v8:6949,v8:11074 Change-Id: I13cc576a26f60288281c42df3326ba902fd36dbb Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2529910 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Santiago Aboy Solanes <solanes@chromium.org> Cr-Commit-Position: refs/heads/master@{#71120}
-
Ross McIlroy authored
Introduces an AtomicUint64 type and a seperate AtomicLoad64 due to the different types returned by loading 64-bit atomic values on 32-bit vs 64-bit architectures. BUG=v8:6949,v8:11074 Change-Id: I95de994df9639847cd6b5fd56ea2a6585189ed3a Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2529455 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Santiago Aboy Solanes <solanes@chromium.org> Auto-Submit: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#71110}
-
- 09 Nov, 2020 1 commit
-
-
Ross McIlroy authored
Moves CallStubR to be private and drop the return_count argument from CallStub and its callchain, and instead use the GetReturnCount on the call descriptor. Also removes unused Retain function from code-assembler. BUG=v8:6949,v8:11074 Change-Id: Ic0ebc72f84c2eab156c545af56237d4c46548c05 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2523324 Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org> Auto-Submit: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Santiago Aboy Solanes <solanes@chromium.org> Cr-Commit-Position: refs/heads/master@{#71038}
-
- 28 Oct, 2020 1 commit
-
-
Shu-yu Guo authored
Change-Id: I4ab54dac771bb551c2435a98f9e53194a6f27853 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2495494 Commit-Queue: Shu-yu Guo <syg@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#70851}
-
- 05 Oct, 2020 1 commit
-
-
Santiago Aboy Solanes authored
As a drive-by, rename "sanity check" to "check" in sharedarraybuffer. Bug: v8:6949, v8:10933 Change-Id: Ifa2eac381ed309a099b018de4033816ebe3d828d Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2429410 Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#70307}
-
- 01 Oct, 2020 1 commit
-
-
Dan Elphick authored
CodeAssembler::Parameter now takes a Type template parameter and performs a checked cast to it. There is also UncheckedParameter which returns a TNode but doesn't check the cast. The original Parameter method is still there as UntypedParameter. Parameter<T>(x) in many cases replaces CAST(Parameter(x)), where the cast is performed inside Parameter. Since Parameter is not a macro, this means it cannot see the original expression or its file name and line number. So the error messages are vaguely useful, Parameter<T>() takes a SourceLocation parameter which with a default value of SourceLocation::Current(), which at least gives us the file name and line number for the error message. Bug: v8:6949, v8:10933 Change-Id: I27157bec7dc7462210c1eb9c430c0180217d25c1 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2435106Reviewed-by: Bill Budge <bbudge@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Santiago Aboy Solanes <solanes@chromium.org> Commit-Queue: Dan Elphick <delphick@chromium.org> Cr-Commit-Position: refs/heads/master@{#70264}
-
- 02 Sep, 2020 1 commit
-
-
Victor Gomes authored
This adds the argument count (as intptr) to the standard frame. StandardFrames are now in the same shape as OptimizedFrames. The argument count in the stack will be used to tear down the arguments when we remove the arguments adaptor frame. Change-Id: If9cc2946321bc1bb0abb776521e2d5b683ab0532 Bug: v8:10201 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2312783 Commit-Queue: Victor Gomes <victorgomes@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Igor Sheludko <ishell@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#69663}
-
- 05 Aug, 2020 1 commit
-
-
Jakob Gruber authored
With the new Turbofan variants (NCI and Turboprop), we need a way to distinguish between them both during and after compilation. We initially introduced CompilationTarget to track the variant during compilation, but decided to reuse the code kind as the canonical spot to store this information instead. Why? Because it is an established mechanism, already available in most of the necessary spots (inside the pipeline, on Code objects, in profiling traces). This CL removes CompilationTarget and adds a new NATIVE_CONTEXT_INDEPENDENT kind, plus helper functions to determine various things about a given code kind (e.g.: does this code kind deopt?). As a (very large) drive-by, refactor both Code::Kind and AbstractCode::Kind into a new CodeKind enum class. Bug: v8:8888 Change-Id: Ie858b9a53311b0731630be35cf5cd108dee95b39 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2336793 Commit-Queue: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Clemens Backes <clemensb@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Dominik Inführ <dinfuehr@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#69244}
-
- 27 Jul, 2020 1 commit
-
-
Tobias Tebbi authored
When mksnapshot fails on a static assert in Torque, print the statement and position from the Torque source. To enable special treatment, change the syntax of static asserts in Torque from StaticAssert() to static_assert() to align with assert() and check() statements. Bug: v8:7793 Change-Id: Idda8e3c342bdcefc893ff297f8d7727d2734c221 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2317314 Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Reviewed-by: Seth Brenith <seth.brenith@microsoft.com> Cr-Commit-Position: refs/heads/master@{#69069}
-
- 24 Jul, 2020 1 commit
-
-
Seth Brenith authored
Otherwise, a failure message from a common macro like UnsafeCast<A> is not particularly meaningful. With this change, the failure message would show the line number in the top-level builtin and each in-between macro that resulted in calling UnsafeCast<A>. This does not include plain CSA macros, only those generated by Torque. Bug: v8:7793 Change-Id: If0b9b7d2755f579ceacf47eef2440d97ec84a2ff Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2303598 Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#69044}
-
- 22 Jul, 2020 2 commits
-
-
Seth Brenith authored
Design doc: https://docs.google.com/document/d/1szInbXZfaErWW70d30hJsOLL0Es-l5_g8d2rXm1ZBqI/edit?usp=sharing V8 can already collect data about how many times each basic block in the builtins is run. This change enables using that data for profile-guided optimization. New comments in BUILD.gn describe how to use this feature. A few implementation details worth mentioning, which aren't covered in the design doc: - BasicBlockProfilerData currently contains an array of RPO numbers. However, this array is always just [0, 1, 2, 3, ...], so this change removes that array. A new DCHECK in BasicBlockInstrumentor::Instrument ensures that the removal is valid. - RPO numbers, while useful for printing data that matches with the stringified schedule, are not useful for matching profiling data with blocks that haven't been scheduled yet. This change adds a new array of block IDs in BasicBlockProfilerData, so that block counters can be used for PGO. - Basic block counters need to be written to a file so that they can be provided to a subsequent run of mksnapshot, but the design doc doesn't specify the transfer format or what file is used. In this change, I propose using the existing v8.log file for that purpose. Block count records look like this: block,TestLessThanHandler,37,29405 This line indicates that block ID 37 in TestLessThanHandler was run 29405 times. If multiple lines refer to the same block, the reader adds them all together. I like this format because it's easy to use: - V8 already has robust logic for creating the log file, naming it to avoid conflicts in multi-process situations, etc. - Line order doesn't matter, and interleaved writes from various logging sources are fine, given that V8 writes each line atomically. - Combining multiple sources of profiling data is as simple as concatenating their v8.log files together. - It is a good idea to avoid making any changes based on profiling data if the function being compiled doesn't match the one that was profiled, since it is common to use profiling data downloaded from a central lab which is updated only periodically. To check whether a function matches, I propose using a hash of the Graph state right before scheduling. This might be stricter than necessary, as some changes to the function might be small enough that the profile data is still relevant, but I'd rather err on the side of not making incorrect changes. This hash is also written to the v8.log file, in a line that looks like this: builtin_hash,LdaZeroHandler,3387822046 Bug: v8:10470 Change-Id: I429e5ce5efa94e01e7489deb3996012cf860cf13 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2220765 Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#69008}
-
Richard Stotz authored
The design of this change was discussed here: https://docs.google.com/document/d/12otOj6SyXMXj0Dnnx9B6MGLMRwHPhg6RIZRazVw3tFA/ Bug: v8:10720 Change-Id: I8292dcf7272bdf4526a2d630b49fc374cdb01bdc Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2304570 Commit-Queue: Richard Stotz <rstz@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Reviewed-by: Andreas Haas <ahaas@chromium.org> Cr-Commit-Position: refs/heads/master@{#68994}
-
- 10 Jul, 2020 1 commit
-
-
Igor Sheludko authored
... by migrating old-style code MyObject* obj = new (zone) MyObject(...) to the new style MyObject* obj = zone->New<MyObject>(...) Bug: v8:10689 Change-Id: Iec2b3102bd35ad7e50b90882ade78d27999a71f2 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2288866Reviewed-by: Michael Stanton <mvstanton@chromium.org> Commit-Queue: Igor Sheludko <ishell@chromium.org> Cr-Commit-Position: refs/heads/master@{#68803}
-
- 28 May, 2020 1 commit
-
-
Nico Hartmann authored
This is a reland of 6204768b The original issue exposed the problem that NumberEqual performs implicit conversion of oddballs to numbers, which is incorrect for abstract equality comparison (i.e. 0 == null must not be true). This reland fixes this by applying the following steps: * Introduced a new kNumberOrBoolean value for CompareOperationFeedback, CompareOperationHint, TypeCheckKind and CheckedTaggedInputMode. * In CodeStubAssembler::Equal: Further distinguish between boolean and non-boolean oddballs and set feedback accoringly. * In JSTypedLowering: Construct [Speculative]NumberEqual operator with CompareOperationHint::kNumberOrBoolean, when this feedback is present. JSOperatorBuilder and operator cache are extended accordingly. * In SimplifiedLowering: Propagate a UseInfo with new TypeCheckKind::kNumberOrBoolean. * This leads to the generation of CheckedTaggedToFloat64 in RepresentationChanger with new CheckedTaggedInputMode::kNumberOrBoolean. * In EffectControlLinearizer: Handle this new mode. Accept and convert number and boolean and deopt for rest. Original change's description: > [turbofan] Improve equality on NumberOrOddball > > This CL cleans up CompareOperationFeedback by replacing it with a > composable set of flags. The interpreter is changed to collect > more specific feedback for abstract equality, especially if oddballs > are involved. > > TurboFan is changed to construct SpeculativeNumberEqual operator > instead of the generic JSEqual in many more cases. This change has > shown a local speedup of a factor of 3-10, because the specific > operator is way faster than calling into the generic builtin, but > it also enables additional optimizations, further improving > runtime performance. > > Bug: v8:5660 > Change-Id: I856752caa707e9a4f742c6e7a9c75552fb431d28 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2162854 > Reviewed-by: Mythri Alle <mythria@chromium.org> > Reviewed-by: Georg Neis <neis@chromium.org> > Commit-Queue: Nico Hartmann <nicohartmann@chromium.org> > Cr-Commit-Position: refs/heads/master@{#67645} TBR: tebbi@chromium.org Bug: v8:5660 Change-Id: I12e733149a1d2773cafb781a1d4b10aa1eb242a7 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2193713 Commit-Queue: Georg Neis <neis@chromium.org> Reviewed-by: Mythri Alle <mythria@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#68037}
-
- 26 May, 2020 1 commit
-
-
Victor Gomes authored
This CL is a step towards reversing JS stack arguments for TurboFan. It does the following: 1. Add StackOrder to CallInterfaceDescriptor 2. Reverse arguments in TF backend for JS calls. 3. Cleanup TFJ builtins interface descriptors, since calls for these builtins already reverse the arguments, we don't need to reverse the interface descriptor anymore. Change-Id: Ie840b1757bf023aa381a7fa01cbe66e7cf90778f Bug: v8:10201 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2213440Reviewed-by: Jakob Gruber <jgruber@chromium.org> Commit-Queue: Victor Gomes <victorgomes@chromium.org> Cr-Commit-Position: refs/heads/master@{#67971}
-
- 08 May, 2020 1 commit
-
-
Nico Hartmann authored
This reverts commit 6204768b. Reason for revert: A number of Clusterfuzz reports (e.g. https://bugs.chromium.org/p/chromium/issues/detail?id=1079474) Original change's description: > [turbofan] Improve equality on NumberOrOddball > > This CL cleans up CompareOperationFeedback by replacing it with a > composable set of flags. The interpreter is changed to collect > more specific feedback for abstract equality, especially if oddballs > are involved. > > TurboFan is changed to construct SpeculativeNumberEqual operator > instead of the generic JSEqual in many more cases. This change has > shown a local speedup of a factor of 3-10, because the specific > operator is way faster than calling into the generic builtin, but > it also enables additional optimizations, further improving > runtime performance. > > Bug: v8:5660 > Change-Id: I856752caa707e9a4f742c6e7a9c75552fb431d28 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2162854 > Reviewed-by: Mythri Alle <mythria@chromium.org> > Reviewed-by: Georg Neis <neis@chromium.org> > Commit-Queue: Nico Hartmann <nicohartmann@chromium.org> > Cr-Commit-Position: refs/heads/master@{#67645} TBR=rmcilroy@chromium.org,neis@chromium.org,mythria@chromium.org,nicohartmann@chromium.org Change-Id: I3410310ed2b1ff2eaee70c1b91c3151d35866108 No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: v8:5660 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2190414Reviewed-by: Nico Hartmann <nicohartmann@chromium.org> Commit-Queue: Nico Hartmann <nicohartmann@chromium.org> Cr-Commit-Position: refs/heads/master@{#67673}
-
- 07 May, 2020 1 commit
-
-
Nico Hartmann authored
This CL cleans up CompareOperationFeedback by replacing it with a composable set of flags. The interpreter is changed to collect more specific feedback for abstract equality, especially if oddballs are involved. TurboFan is changed to construct SpeculativeNumberEqual operator instead of the generic JSEqual in many more cases. This change has shown a local speedup of a factor of 3-10, because the specific operator is way faster than calling into the generic builtin, but it also enables additional optimizations, further improving runtime performance. Bug: v8:5660 Change-Id: I856752caa707e9a4f742c6e7a9c75552fb431d28 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2162854Reviewed-by: Mythri Alle <mythria@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Commit-Queue: Nico Hartmann <nicohartmann@chromium.org> Cr-Commit-Position: refs/heads/master@{#67645}
-
- 23 Apr, 2020 1 commit
-
-
Bill Budge authored
- Use the new builtin to convert f32 to Number, rather than changing to f64, then calling f64 to Number. Bug: v8:10070 Change-Id: I9a0660af8f5e517c2c6691d57d665b7e6316a51b Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2111714 Commit-Queue: Bill Budge <bbudge@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/master@{#67342}
-
- 21 Apr, 2020 1 commit
-
-
Bill Budge authored
- Adds builtins to convert between Int32/Float64 and JS Number. - WasmInt32ToHeapNumber (bypass SMI test) - WasmFloat64ToNumber - Adds builtins to convert between Tagged and Int32/Float64. - WasmTaggedNonSmiToInt32 (bypass SMI test) - WasmTaggedToFloat64 - Uses these builtins in Wasm import and export wrappers instead of generating the equivalent code inline. Results of running Wasm/import-export-wrappers.js Benchmark: https://docs.google.com/document/d/1QIB0xnqdJFRsOJKQYZ8DZgzWn4WysybgugbcO0sYcQA/edit?usp=sharing NOTE: CL will need to be rebased after linkage fix lands. Bug: v8:10070 Change-Id: Ib34507fcd18bdf80938b5707310a5a4f76cdec72 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2099445Reviewed-by: Andreas Haas <ahaas@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Clemens Backes <clemensb@chromium.org> Commit-Queue: Bill Budge <bbudge@chromium.org> Cr-Commit-Position: refs/heads/master@{#67292}
-
- 10 Mar, 2020 1 commit
-
-
Victor Gomes authored
The arguments order in a JS stack is now controlled by V8_REVERSE_JSARGS macro. This CL creates two stubs that allow the order of the arguments to be reversed without changing CallStub. Bug: v8:10201 Change-Id: I8f70adf3ced1f45a00f5c4ddd47d5f604f2d3100 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2093506 Commit-Queue: Victor Gomes <victorgomes@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#66647}
-
- 25 Feb, 2020 1 commit
-
-
Dan Elphick authored
Makes RoundIntPtrToFloat64 return TNode<Float64T> instead of Node*. Bug: v8:10155 Change-Id: I1edd5456b2b86b264b66eeab5e46ceb2a1f0170f Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2064978 Commit-Queue: Dan Elphick <delphick@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#66421}
-
- 18 Feb, 2020 1 commit
-
-
Georg Neis authored
... in favor of CodeAssembler's ScopedExceptionHandler. Also remove unused exception arguments from some iterator related methods. Bug: v8:10187 Change-Id: I8eb7dfd4eb339e4f566970efa5757c3771926ba6 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2060496 Commit-Queue: Georg Neis <neis@chromium.org> Auto-Submit: Georg Neis <neis@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#66306}
-
- 17 Feb, 2020 2 commits
-
-
Santiago Aboy Solanes authored
Bug: v8:6949, v8:10155 Change-Id: I0113efe2d4d3a462533c306a87ebee851b1cb85c Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2056853Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org> Cr-Commit-Position: refs/heads/master@{#66286}
-
Santiago Aboy Solanes authored
Bug: v8:6949, v8:10155 Change-Id: Iafd6b8172a67fa1b778d163259fe8d1400b004f3 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2056847Reviewed-by: Dan Elphick <delphick@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org> Cr-Commit-Position: refs/heads/master@{#66282}
-
- 14 Feb, 2020 1 commit
-
-
Santiago Aboy Solanes authored
Bug: v8:6949, v8:10155 Change-Id: Id170bafa2a5085bee6ff5b3cff8084254c67e113 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2056846Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Dan Elphick <delphick@chromium.org> Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org> Cr-Commit-Position: refs/heads/master@{#66275}
-
- 07 Feb, 2020 2 commits
-
-
Igor Sheludko authored
Bug: v8:10047 Change-Id: I140fcf453ce7dd6189e0f643f95570163b625456 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2043831 Commit-Queue: Igor Sheludko <ishell@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#66173}
-
Igor Sheludko authored
... a Smi-looking type containing properly sign-extended int31 integer. The idea is to use this kind of tagged integers for the cases where the value is guaranteed to fit into int31. For example, feedback vector slots is one of the candidates for using TaggedIndex representation. Bug: v8:10047 Change-Id: Ifaa2978a5d42467578ff243dc44d327536efbe93 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1960292Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Commit-Queue: Igor Sheludko <ishell@chromium.org> Cr-Commit-Position: refs/heads/master@{#66170}
-
- 10 Jan, 2020 1 commit
-
-
Nico Hartmann authored
Many binary operations defiend in CodeAssembler check for constants in the inputs and apply simplification if applicable. This is now performed by the MachineOperatorReducer in a uniform way. To avoid code duplication, the premature optimizations in CodeAssembler have been removed in this CL. Bug: v8:10021 Change-Id: I9b99f05e4f9ab31ff933f22d62674ee80efee8ac Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1995277Reviewed-by: Maya Lekova <mslekova@chromium.org> Commit-Queue: Nico Hartmann <nicohartmann@chromium.org> Cr-Commit-Position: refs/heads/master@{#65707}
-
- 20 Dec, 2019 1 commit
-
-
Tobias Tebbi authored
This is a reland of 53308bf7 Original change's description: > [csa] use JSGraph to create constants in CodeAssembler > > Now that CodeAssembler uses optimizing TurboFan passes, creating > constants without using the caching implemented in JSGraph leads to > problems, since value numbering only works properly if all constants > in the graph were introduced through the cache. > To mitigate this, this CL creates the JSGraph earlier so that > CodeAssembler can already use the same JSGraph used by later TurboFan > optimizations. > For other uses of RawMachineAssembler, everything stays as before. > > This issue is creating bot failures in > https://chromium-review.googlesource.com/c/v8/v8/+/1958011 > > Change-Id: Ife017876b19cb2602694279ef1da75f23e18a031 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1967329 > Reviewed-by: Maya Lekova <mslekova@chromium.org> > Commit-Queue: Tobias Tebbi <tebbi@chromium.org> > Cr-Commit-Position: refs/heads/master@{#65477} TBR=mslekova@chromium.org Change-Id: I5c8218ce22470b3efa06d872176c910a4c5325a4 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1977858Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#65537}
-
- 17 Dec, 2019 2 commits
-
-
Clemens Backes authored
This reverts commit 53308bf7. Reason for revert: Fails on multiple arm bots, e.g. https://ci.chromium.org/p/v8/builders/ci/V8%20Arm%20-%20debug/12441 Original change's description: > [csa] use JSGraph to create constants in CodeAssembler > > Now that CodeAssembler uses optimizing TurboFan passes, creating > constants without using the caching implemented in JSGraph leads to > problems, since value numbering only works properly if all constants > in the graph were introduced through the cache. > To mitigate this, this CL creates the JSGraph earlier so that > CodeAssembler can already use the same JSGraph used by later TurboFan > optimizations. > For other uses of RawMachineAssembler, everything stays as before. > > This issue is creating bot failures in > https://chromium-review.googlesource.com/c/v8/v8/+/1958011 > > Change-Id: Ife017876b19cb2602694279ef1da75f23e18a031 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1967329 > Reviewed-by: Maya Lekova <mslekova@chromium.org> > Commit-Queue: Tobias Tebbi <tebbi@chromium.org> > Cr-Commit-Position: refs/heads/master@{#65477} TBR=tebbi@chromium.org,mslekova@chromium.org Change-Id: I6df6782adfb40632f51681942efab9b591f72cab No-Presubmit: true No-Tree-Checks: true No-Try: true Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1969901Reviewed-by: Clemens Backes <clemensb@chromium.org> Commit-Queue: Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/master@{#65483}
-
Tobias Tebbi authored
Now that CodeAssembler uses optimizing TurboFan passes, creating constants without using the caching implemented in JSGraph leads to problems, since value numbering only works properly if all constants in the graph were introduced through the cache. To mitigate this, this CL creates the JSGraph earlier so that CodeAssembler can already use the same JSGraph used by later TurboFan optimizations. For other uses of RawMachineAssembler, everything stays as before. This issue is creating bot failures in https://chromium-review.googlesource.com/c/v8/v8/+/1958011 Change-Id: Ife017876b19cb2602694279ef1da75f23e18a031 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1967329Reviewed-by: Maya Lekova <mslekova@chromium.org> Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#65477}
-
- 11 Dec, 2019 1 commit
-
-
Jakob Kummerow authored
Found by combining dcheck_always_on with is_ubsan on x64. Change-Id: Ie9bcf2402693aa3752be17421dd485533656df08 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1962271Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Commit-Queue: Jakob Kummerow <jkummerow@chromium.org> Cr-Commit-Position: refs/heads/master@{#65417}
-
- 28 Nov, 2019 1 commit
-
-
Michael Starzinger authored
R=tebbi@chromium.org BUG=v8:10021 Change-Id: I39052fa22ea90b392a36e7841f8586c19c8ca9cf Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1940156 Commit-Queue: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#65229}
-