- 25 Nov, 2019 10 commits
-
-
Clemens Backes authored
In the declaration, callers, and in the {ConvertFloatToUint64} helper, the parameter is called "fail". In the definition, it's wrongly called "success". R=ahaas@chromium.org Change-Id: Iec861f182e54165e609c6e61d399ceb87512054f Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1930900Reviewed-by:Andreas Haas <ahaas@chromium.org> Commit-Queue: Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/master@{#65142}
-
Dan Elphick authored
Converts and uses of RuntimeCallTimerScopes that switch the counter based on the thread, to use kThreadSpecific and remove the counter selection. Also moves RuntimeCallTimerScope::CounterMode to RuntimeCallStats, since now CorrectCurrentCounterId also takes it as a parameter. Bug: v8:10006 Change-Id: I14a503e0b83bb69c071f9665956de094bb33c0ba Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1928864Reviewed-by:
Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Dan Elphick <delphick@chromium.org> Cr-Commit-Position: refs/heads/master@{#65141}
-
Michael Achenbach authored
This adds a regresson test case for the revert reason of: https://crrev.com/c/1906378 The test data is tidied up by keeping the different fake d8s in separate build directories like it would be in production. A new test simulates an architecture difference and ensures we pass the architecture mocks in all runs. No-Try: true Bug: chromium:1023091 Change-Id: Ic33c426ba8eb9c4b6b0fbb66d43c0859dc2edfcd Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1918248 Commit-Queue: Michael Achenbach <machenbach@chromium.org> Reviewed-by:
Tamer Tas <tmrts@chromium.org> Cr-Commit-Position: refs/heads/master@{#65140}
-
Georg Neis authored
Allow sharing of hints and modification of shared hints such that feedback can be propagated to the hints for the corresponding register, AND all alias registers. Even propagation from an inlined callee back to the caller is possible. Bug: v8:7790 Change-Id: I96b3c5e41613efa5711ab758db1c3ef7f7ae6418 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1914560 Commit-Queue: Georg Neis <neis@chromium.org> Reviewed-by:
Maya Lekova <mslekova@chromium.org> Reviewed-by:
Michael Stanton <mvstanton@chromium.org> Cr-Commit-Position: refs/heads/master@{#65139}
-
Leszek Swirski authored
During conflict lookup (for lexical variables and sloppy block function hoisting), we cache the looked-up variable on the current scope if the lookup goes through a ScopeInfo. However, for variable lookup during scope analysis, we use the "entry point" as the cache. Since both lookups can create Variables, this can cause us to create duplicate variables, e.g. a duplicate function name variable in the attached test. Instead, for ScopeInfo conflict lookups we can cache the result on the function's outer scope, which shoud be equivalent to the entry point. As a (necessary) drive-by, we can terminate the lookup early if we find a VAR with the same name, as we can safely assume that its existence means that it doesn't conflict, which means that our variable can't conflict either. Bug: chromium:1026603 Change-Id: I19f80f65597ba6573ebe0b48aa5698f55e5c3ea1 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1928861 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by:
Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#65138}
-
David Carlier authored
Pretty similar than other oses except we check LLVM/clang usage. Upstreaming local FreeBSD patches. Change-Id: Ife8447a9ff35e30a92134f65a2d8394d5123d9ab Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1910108 Commit-Queue: Ulan Degenbaev <ulan@chromium.org> Reviewed-by:
Ulan Degenbaev <ulan@chromium.org> Cr-Commit-Position: refs/heads/master@{#65137}
-
Igor Sheludko authored
Chromium LSAN bot failures are fixed on Chromium side: https://chromium-review.googlesource.com/c/chromium/src/+/1926472 Bug: v8:7703 Change-Id: I830b747ca2f2f1b3c5adf31b42b3b8112c5d4457 Cq-Include-Trybots: luci.v8.try:v8_linux64_ubsan_rel_ng,v8_linux64_tsan_rel Cq-Include-Trybots: luci.v8.try:v8_linux64_cfi_rel_ng Cq-Include-Trybots: luci.chromium.try:fuchsia_x64,linux-rel,mac-rel,linux_chromium_asan_rel_ng Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1925149Reviewed-by:
Michael Achenbach <machenbach@chromium.org> Commit-Queue: Igor Sheludko <ishell@chromium.org> Cr-Commit-Position: refs/heads/master@{#65136}
-
Gus Caplan authored
Properly handle termination exceptions in TLA modules. Bug: v8:9978 Change-Id: Ica70a55d1f54ec89d175d7c846e9a405eaffe0a0 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1920750 Commit-Queue: Georg Neis <neis@chromium.org> Reviewed-by:
Georg Neis <neis@chromium.org> Reviewed-by:
Yang Guo <yangguo@chromium.org> Reviewed-by:
Joshua Litt <joshualitt@chromium.org> Cr-Commit-Position: refs/heads/master@{#65135}
-
Michael Achenbach authored
Refbuilds still require natives blob. We need to keep the logic for handling it on android until the next branch point. No-Try: true Bug: chromium:1026556 Change-Id: I8375400e0d3ea0f881ef56edc7de8574ae94f3e0 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1928862Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Commit-Queue: Michael Achenbach <machenbach@chromium.org> Cr-Commit-Position: refs/heads/master@{#65134}
-
v8-ci-autoroll-builder authored
Rolling v8/build: https://chromium.googlesource.com/chromium/src/build/+log/7a7c931..7875528 Rolling v8/tools/clang: https://chromium.googlesource.com/chromium/src/tools/clang/+log/5b2f5c6..4d65f00 TBR=machenbach@chromium.org,tmrts@chromium.org Change-Id: I6e3cf4e97fe928b02de026b878bdafe59b30df1f Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1933190Reviewed-by:
v8-ci-autoroll-builder <v8-ci-autoroll-builder@chops-service-accounts.iam.gserviceaccount.com> Commit-Queue: v8-ci-autoroll-builder <v8-ci-autoroll-builder@chops-service-accounts.iam.gserviceaccount.com> Cr-Commit-Position: refs/heads/master@{#65133}
-
- 24 Nov, 2019 1 commit
-
-
v8-ci-autoroll-builder authored
Rolling v8/build: https://chromium.googlesource.com/chromium/src/build/+log/75b91a2..7a7c931 Rolling v8/third_party/depot_tools: https://chromium.googlesource.com/chromium/tools/depot_tools/+log/556c0a2..8001297 TBR=machenbach@chromium.org,tmrts@chromium.org Change-Id: Ia59597b2eb46666a63b632150da87c7d5f00be10 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1932606Reviewed-by:
-
- 23 Nov, 2019 1 commit
-
-
v8-ci-autoroll-builder authored
Rolling v8/build: https://chromium.googlesource.com/chromium/src/build/+log/1ab161c..75b91a2 Rolling v8/third_party/catapult: https://chromium.googlesource.com/catapult/+log/536c641..5459c38 Rolling v8/third_party/depot_tools: https://chromium.googlesource.com/chromium/tools/depot_tools/+log/c50b096..556c0a2 Rolling v8/third_party/icu: https://chromium.googlesource.com/chromium/deps/icu/+log/88ea42a..dbd3825 TBR=machenbach@chromium.org,tmrts@chromium.org Change-Id: I3d98cc1d82e7c937dbe8cd22323069310efcb5ff Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1931624Reviewed-by:
-
- 22 Nov, 2019 21 commits
-
-
Ng Zhi An authored
Fixed: v8:9980 Bug: v8:9198 Change-Id: I26635302bb0c2a20bfd4ac6bb7f513f81c2f45f0 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1930068Reviewed-by:
Bill Budge <bbudge@chromium.org> Commit-Queue: Zhi An Ng <zhin@chromium.org> Cr-Commit-Position: refs/heads/master@{#65130}
-
Ng Zhi An authored
With https://crrev.com/c/1925524 we are moving elements on the stack by their offset, but this transfer recipe is still checking the indices of src and dst, which is incorrect. Bug: chromium:1027410 Change-Id: Id7c7523c097bd06f3d107cb4d9de1052fc082105 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1930606Reviewed-by:
Clemens Backes <clemensb@chromium.org> Commit-Queue: Zhi An Ng <zhin@chromium.org> Cr-Commit-Position: refs/heads/master@{#65129}
-
Ng Zhi An authored
This test was generated following instructions in https://crbug.com/1026680#c4, it seg faults with https://crrev.com/c/1922489 and passes with the reland https://crrev.com/c/1925131. Bug: chromium:1026680 Change-Id: Ia8ef9878c06c50adeaa1a441524b5555b6869f97 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1930604 Commit-Queue: Zhi An Ng <zhin@chromium.org> Reviewed-by:
-
Mike Stanton authored
FunctionBlueprint holds a SharedFunctionInfo, FeedbackVector and a Hints object that represents what we know about the Context of the "function-to-be." Since we occasionally synthesize a FunctionBlueprint object from a JSFunction (when we have it), it can happen that sometimes the Context hint is a concrete Context object, and other times it's a VirtualContext, representing a context created sometime during the bytecode execution of the function under optimization. Moreover, both such FunctionBlueprints can exist in the same run due to the vagaries of CALL_IC feedback (ie, sometimes you have a JSFunction, other times you don't). More details in doc: https://docs.google.com/document/d/1F1FxoDzlaYP5l5T6ZcZacV3LCUp5elcez05KWj-Mp78/edit?usp=sharing Bug: crbug:1024282 Change-Id: Id4055531333b3dcbdb93afd23d9a226728292e11 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1926151 Commit-Queue: Michael Stanton <mvstanton@chromium.org> Reviewed-by:
-
Zhao Jiazhong authored
port aafbc138 https://crrev.com/c/1900662 Original Commit Message: [wasm-simd] Implement i64x2 shifts for arm Change-Id: I036610bdcf8e36879cf7a47fbf6e28034345a945 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1928499 Auto-Submit: Zhao Jiazhong <zhaojiazhong-hf@loongson.cn> Reviewed-by:
-
Dan Elphick authored
RuntimeCallTimerScope can now be called with the optional flag kThreadSpecific, which chooses the appropriate RuntimeCounterId given whether the RuntimeCallStats object is for the main isolate thread or a worker thread. While this doesn't change any existing timers over to use this flag it does add checks that in the default case that any thread-specific counters are the correct one given the thread status. Bug: v8:10006 Change-Id: Idb545714284bcd2e2fdca991918ddf976dcbdf70 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1928863 Commit-Queue: Dan Elphick <delphick@chromium.org> Reviewed-by:
Mythri Alle <mythria@chromium.org> Cr-Commit-Position: refs/heads/master@{#65125}
-
Zhao Jiazhong authored
port ea06b01e https://crrev.com/c/1925613 Original Commit Message: [wasm-simd] Implement i64x2 add sub for arm Also some cleanup reordering of instruction codes. Change-Id: I151668f4125c46b35b08ddd3640341125f6fdbdf Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1928500 Auto-Submit: Zhao Jiazhong <zhaojiazhong-hf@loongson.cn> Reviewed-by:
-
Zhao Jiazhong authored
The previous implementation incorrectly used instructions for 32-bit data, this CL fixes it to implement 64-bit operations. Change-Id: Ib8e5236ea35f3a2c0e37e647ea89aad6a1127425 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1928501 Auto-Submit: Zhao Jiazhong <zhaojiazhong-hf@loongson.cn> Reviewed-by:
-
Z Nguyen-Huu authored
This scenario is where user is at the end of Wasm execution and do some stepping. Hence, user should be back at Javascript frame. We can detect that stepping as it exits Wasm Interpreter and prepare debugging as a step-out-ish in Javascript. Bug: chromium:823923, chromium:1019606, chromium:1025151 Change-Id: I29022af0d5e5dcf78d87e83193f6e16fec954e87 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1912985 Commit-Queue: Z Nguyen-Huu <duongn@microsoft.com> Reviewed-by:
Benedikt Meurer <bmeurer@chromium.org> Cr-Commit-Position: refs/heads/master@{#65122}
-
Ng Zhi An authored
Bug: v8:10007 Change-Id: Ic65bb2846ee21f7ec58ced8b2d3bcf2cbb810da9 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1928622Reviewed-by:
-
Ulan Degenbaev authored
Currently these events are emitted by Blink in GC prologue/epilogue. That however does not respect event nesting and breaks with future perfetto changes. This CL emits the events inside V8 using a scope to guarantee proper event nesting. The events are same except for the "type" argument that now gets more detailed information. The corresponding Blink CL that removes these trace events: https://chromium-review.googlesource.com/c/chromium/src/+/1929227 Bug: chromium:1026658 Change-Id: Ifbfab647f40f81af7acf315ff4608b9dc9444f94 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1928857Reviewed-by:
-
Toon Verwaest authored
We possibly need to load the global object from the global proxy as the holder of the named interceptor. Change-Id: I0f9f2e448630608ae853588f6751b55574a9efd9 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1930903 Commit-Queue: Igor Sheludko <ishell@chromium.org> Reviewed-by:
Igor Sheludko <ishell@chromium.org> Cr-Commit-Position: refs/heads/master@{#65119}
-
Joshua Litt authored
Bug: v8:9838 Change-Id: I7597e55744c577bd1a7619110db88e1adb4239a2 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1922488 Commit-Queue: Joshua Litt <joshualitt@chromium.org> Reviewed-by:
-
Tobias Tebbi authored
This is a first step towards allowing expressions for array sizes. So far, local variable bindings used a VisitResult and a const flag. This doesn't allow for local bindings to alias other things, like heap references. While this is not generally a feature we need, it will be helpful to create bindings when evaluating array sizes, since we want to grant access to the preceding already initialized object fields, but not to the whole object, which is not completely initialized yet. LocationReference already captures the notion of any readable and assignable location, so it is a good fit to be used for local bindings. The const attribute is no longer needed, since LocationReference already has a notion of constness for stack ranges (that is, LocationReference::Temporary vs LocationReference::VariableAccess). Bug: v8:10004 v8:7793 Change-Id: Ibe0a43e898e5c2c10d6739e2496d92dda542e6cc Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1928852Reviewed-by:
Nico Hartmann <nicohartmann@chromium.org> Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#65117}
-
Liviu Rau authored
NOTRY=true Bug: chromium:1018724 Change-Id: If98362a88d3a52840c3189d9c8592d07366d3912 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1930555 Commit-Queue: Liviu Rau <liviurau@chromium.org> Reviewed-by:
-
Dan Elphick authored
R=mslekova@chromium.org Bug: v8:9992 Change-Id: I970b919e456257f5776454edceb0bcc1c40eff7d Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1930556 Auto-Submit: Dan Elphick <delphick@chromium.org> Commit-Queue: Maya Lekova <mslekova@chromium.org> Reviewed-by:
-
Steve Blackburn authored
This CL adds build flags for pluging in third-party heap implementation. Additionally it redirects allocation requests when the flags are on. Bug: v8:9533 Change-Id: I7ef300ca9dc2b5f498a13211611ae4b4b3df8fa0 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1928860 Commit-Queue: Ulan Degenbaev <ulan@chromium.org> Reviewed-by:
-
Clemens Backes authored
A previous CL (https://crrev.com/c/1926769) changed hashing to always treat the input as signed values. This causes problems, since the hash of a one-byte string differs the hash of the identical two-byte string. Hence this CL switches to treating all values as unsigned in hashing. The bug cannot easily be reproduced in v8 alone, since we would need to create an internalized two-byte string, which contains one-byte data. Blink manages to create such a string via external strings. R=jkummerow@chromium.org Bug: chromium:1025184, chromium:1027131 Change-Id: Id41aa0e463691c02099a08c6e9d837a079c872df Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1930615Reviewed-by:
Jakob Kummerow <jkummerow@chromium.org> Commit-Queue: Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/master@{#65113}
-
Clemens Backes authored
If v8_enable_object_print is set to true, we should use Object::Print instead of Brief(Object). R=jkummerow@chromium.org Change-Id: I70583c15834f9332aba7760b5e104136712d4e0d Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1930613Reviewed-by:
-
Liviu Rau authored
Bug: v8:9898 Change-Id: Id8a5ca983e80c00d23180ff3bcff51571513961b Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1900456Reviewed-by:
-
v8-ci-autoroll-builder authored
Rolling v8/build: https://chromium.googlesource.com/chromium/src/build/+log/a5a3b9f..1ab161c Rolling v8/third_party/catapult: https://chromium.googlesource.com/catapult/+log/988a272..536c641 Rolling v8/third_party/depot_tools: https://chromium.googlesource.com/chromium/tools/depot_tools/+log/2e2f587..c50b096 TBR=machenbach@chromium.org,tmrts@chromium.org Change-Id: Icbbd441aff681b39273b1c10832750b788d968b6 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1928889Reviewed-by:
-
- 21 Nov, 2019 7 commits
-
-
Ng Zhi An authored
This patch changes many callers of GetStackOffsetFromIndex to directly use the offset that is stored in the VarState (and other structures). The tricky part here is that in all archs, GetStackSlotOffset no longer relies on kFirstStackSlotOffset, because the offset stored in VarState is relative to the constant space (instance offset), and not offset of the first stack slot. For example, for slot 0, the offset was also 0, because it was relative to the first stack slot offset (which in x64 is fp-24). With this change, the offset of slot 0 is now 8, but since GetStackSlotOffset is relative to fp-16, it ends up being fp-24 still. Because of this change, callers of GetStackOffsetFromIndex need to add 1 to whatever index they were passing. Instead of doing that, we change GetStackOffsetFromIndex to add 1 inside the body. After this change, the only callers of GetStackOffsetFromIndex will be inside of FillStackSlotsWithZero, because they still rely on index to keep track of how many params were processed, and also how many locals there are in order to zero those slots, and these is relied on by RecordUsedSpillSlot to allocate sufficient stack space. Bug: v8:9909 Change-Id: I52aa4572950565a39e9395192706a9934ac296d4 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1925524 Commit-Queue: Zhi An Ng <zhin@chromium.org> Reviewed-by:
-
Tobias Tebbi authored
This introduces a new keyword "shape" in addition to "class", which allows the definition of a type that extends a JSObject subclass and specifies one or several maps with statically known in-object properties. Differences compared to normal classes: - Shapes are transient since they specify maps instead of instance types. - Shapes have a known size. - Fields of shapes are always in-object properties. In particular, this means that their offset is after kHeaderSize. - It's forbidden to inherited from shapes. - Since shapes usually specify NativeContext-dependent maps, it's not possible to write runtime type-checks for them. Thus this CL avoids mapping them to their own TNode type, as the CAST macro won't work properly. We had runtime-checks for some of them nevertheless, some of them scarily confusing like IsJSSloppyArgumentsObject, that actually just checked the instance type. Drive-by cleanups and simplifications: - Allow subclassing from non-abstract classes and remove @dirtyInstantiatedAbstractClass. This attribute stems from a mis- conception of how instance types work, and with this change it ceases to have semantic influence. - Replace the existing JSArgumentsObject subclasses into two shapes. JSArgumentsObjectWithLength had to be removed since shapes don't support subclassing. - Place kHeaderSize correctly for objects with indexed fields. Design doc: https://docs.google.com/document/d/1zPy2ZYfNFjeEuw6Mz3YJA-GaPGbdcSYam3SrS7ETzRU Bug: v8:8944 Change-Id: Iabf185ccd27d0900e0890539a7fe9eaa8bf2d50e Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1917140 Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Reviewed-by:
-
Ng Zhi An authored
This is a reland of 20727725 The fix is in liftoff-assembler-arm64.h in FillStackSlotsWithZero, in the else case for bigger counts to fill, the argument passed to Sub was incorrect. We were passing offset relative to first slot, but it should be offset relative to instance, so there is an off by 1 slot error when zeroing, and ended up zeroing the stack slot holding instance. Original change's description: > [liftoff] Use stack slot offsets instead of indices > > Spill/fill now take offsets instead of indices. We provide a > helper, GetStackOffsetFromIndex, for callers. This is currently only > useful while slot sizes are still fixed to 8 bytes. > > StackTransferRecipe's RegisterLoad now works in terms of offset. > > LiftoffStackSlots work in terms of offset as well. > > TransferStackSlot currently still works in terms of indicies, but can be > converted to use offsets in a subsequent change. > > Bug: v8:9909 > Change-Id: If54fb844309bdfd641720d063135dd59551813e0 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1922489 > Reviewed-by: Clemens Backes <clemensb@chromium.org> > Commit-Queue: Zhi An Ng <zhin@chromium.org> > Cr-Commit-Position: refs/heads/master@{#65049} Bug: v8:9909 Change-Id: I311da9d3bb1db8faf8693079177c77a7b3754243 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1925131Reviewed-by:
-
Johannes Henkel authored
New revision: 4c2a3acaea9f2e7958081dd361f81e20e9eff5e7 This cleanup cl does not change any behavior, it just cleans up some headers and does a class rename (StreamingParserHandler->ParserHandler). It was reviewed upstream https://chromium-review.googlesource.com/c/deps/inspector_protocol/+/1924792 https://chromium-review.googlesource.com/c/deps/inspector_protocol/+/1925679 and does not touch V8 code. Would like to get this in to make it easier to review subsequent changes. Thanks! Change-Id: Ie9fe1434bafeb4f5090244f823d1e482ff805dd0 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1925721 Auto-Submit: Johannes Henkel <johannes@chromium.org> Reviewed-by:
-
Milad Farazmand authored
Port aafbc138 R=zhin@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com BUG= LOG=N Change-Id: I1b6f70fbf58dc9e32f37ecd5e2030f6966a90842 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1929074Reviewed-by:
Junliang Yan <jyan@ca.ibm.com> Commit-Queue: Milad Farazmand <miladfar@ca.ibm.com> Cr-Commit-Position: refs/heads/master@{#65105}
-
v8-ci-autoroll-builder authored
Rolling v8/build: https://chromium.googlesource.com/chromium/src/build/+log/9f9c46f..a5a3b9f Rolling v8/third_party/android_ndk: https://chromium.googlesource.com/android_ndk/+log/89e8db0..27c0a8d Rolling v8/third_party/catapult: https://chromium.googlesource.com/catapult/+log/4c9781e..988a272 Rolling v8/third_party/depot_tools: https://chromium.googlesource.com/chromium/tools/depot_tools/+log/639872c..2e2f587 Rolling v8/tools/clang: https://chromium.googlesource.com/chromium/src/tools/clang/+log/7506d59..5b2f5c6 TBR=machenbach@chromium.org,tmrts@chromium.org Bug: chromium:1027059 Change-Id: I4aee68f37435c918a5e228ee96417f9e2462cd38 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1928258 Commit-Queue: Michael Achenbach <machenbach@chromium.org> Reviewed-by:
-
Zhao Jiazhong authored
port a7b9e588 https://crrev.com/c/1900661 Original Commit Message: [wasm-simd] Implement i64x2 neg for arm Change-Id: Ia4f52b26e4c3d6e2833b01246bd917d5e62ca79d Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1924003Reviewed-by:
-
