- 16 Nov, 2018 18 commits
-
-
Clemens Hammacher authored
For short inputs (<= size of the type we want to generate), we fell back to just generating constants. This CL changes that to only fall back to constants once a single byte remains, and adds options to use constants already before that. R=ahaas@chromium.org Bug: v8:894307 Change-Id: Ic4bf05d06090f52b67de2b322a9d5dcab6bbbe39 Reviewed-on: https://chromium-review.googlesource.com/c/1337739Reviewed-by:
Andreas Haas <ahaas@chromium.org> Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Cr-Commit-Position: refs/heads/master@{#57573}
-
Ben L. Titzer authored
This CL implements an assembly order optimization that moves blocks that end a loop with an unconditional backedge to the beginning of the loop, saving a branch. R=jarin@chromium.org,mstarzinger@chromium.org BUG=v8:8423 Change-Id: I8a5d25f5472d71227af0f623277ea8d0a8d69867 Reviewed-on: https://chromium-review.googlesource.com/c/1335944 Commit-Queue: Ben Titzer <titzer@chromium.org> Reviewed-by:
Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#57572}
-
Jaroslav Sevcik authored
This reverts commit 3ca32e98. Reason for revert: Breaks waterfall (V8 fuzzer) Original change's description: > [regexp] Introduce species constructor protector for regexps. > > Bug: v8:8445 > Change-Id: Iea69c65d0054b24b3f8c7234c4c556ebee2dd45f > Reviewed-on: https://chromium-review.googlesource.com/c/1335696 > Reviewed-by: Jakob Gruber <jgruber@chromium.org> > Reviewed-by: Ulan Degenbaev <ulan@chromium.org> > Commit-Queue: Jaroslav Sevcik <jarin@chromium.org> > Cr-Commit-Position: refs/heads/master@{#57564} TBR=ulan@chromium.org,jarin@chromium.org,jgruber@chromium.org Change-Id: I8f926abdd129d9868f2c9c5dbb29096c08bd1ff7 No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: v8:8445 Reviewed-on: https://chromium-review.googlesource.com/c/1340239Reviewed-by:
Jaroslav Sevcik <jarin@chromium.org> Commit-Queue: Jaroslav Sevcik <jarin@chromium.org> Cr-Commit-Position: refs/heads/master@{#57571}
-
Benedikt Meurer authored
This adds a new C++ API method ```cpp Local<Object> Object::New( Isolate* isolate, Local<Value> prototype_or_null, Local<Name>* keys, Local<Value>* values, size_t size); ``` which is similar to the `Object.create()` builtin exposed by JavaScript. This new API is supposed to be used by the `http2` (in Node.js) to speed up the creation of the HTTP header object. Bug: v8:8422 Change-Id: I9910e88de0af2cbd8ce8a1d6cb6caa9451fb8cb4 Design-Document: http://bit.ly/v8-fast-object-create-cpp Reviewed-on: https://chromium-review.googlesource.com/c/1337569 Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by:
Yang Guo <yangguo@chromium.org> Reviewed-by:
Ulan Degenbaev <ulan@chromium.org> Reviewed-by:
Camillo Bruni <cbruni@chromium.org> Cr-Commit-Position: refs/heads/master@{#57570}
-
Ross McIlroy authored
With BytecodeArray flushing the SFI->BytecodeArray pointer will become pseudo weak. In order to prevent instrumented bytecode from being flushed while the function is being debugged, hold onto the instrumented bytecode strongly. BUG=v8:8395 Change-Id: Ie346732b77833afa0595a84a4956295e50855392 Reviewed-on: https://chromium-review.googlesource.com/c/1312849Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#57569}
-
Toon Verwaest authored
Bug: chromium:905587 Change-Id: I168fdfd433edcda61dcefd0df9df8a12c5294339 Reviewed-on: https://chromium-review.googlesource.com/c/1340040 Commit-Queue: Toon Verwaest <verwaest@chromium.org> Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#57568}
-
Georg Neis authored
This fixes building with 'v8_enable_trace_ignition = true'. Change-Id: I991b3eaba2e1a50fe9f08ae5dec765c8257a5c26 Reviewed-on: https://chromium-review.googlesource.com/c/1340039Reviewed-by:
-
Yang Guo authored
Bug: chromium:905940 Change-Id: I1d0cd85e7d8b32c08a6b680af5c2bde5adeb9259 Reviewed-on: https://chromium-review.googlesource.com/c/1339699Reviewed-by:
Toon Verwaest <verwaest@chromium.org> Commit-Queue: Yang Guo <yangguo@chromium.org> Cr-Commit-Position: refs/heads/master@{#57566}
-
Toon Verwaest authored
Bug: chromium:905907 Change-Id: I889a47dac1f240f3d656f41f43425cd7cd764c79 Reviewed-on: https://chromium-review.googlesource.com/c/1339862Reviewed-by:
-
Jaroslav Sevcik authored
Bug: v8:8445 Change-Id: Iea69c65d0054b24b3f8c7234c4c556ebee2dd45f Reviewed-on: https://chromium-review.googlesource.com/c/1335696Reviewed-by:
-
Jakob Gruber authored
This marks the InterpreterEntryTrampoline as isolate-independent. With this change, all builtins are now embedded. Slight changes were needed to how we deopt into the trampoline. We now store the entry address within the Interpreter class instead of embedding the builtin code target. Bug: v8:7777 Change-Id: If781bf6f06cb2efbab1369ece757f04c343a1b38 Reviewed-on: https://chromium-review.googlesource.com/c/1337734Reviewed-by:
Ross McIlroy <rmcilroy@chromium.org> Reviewed-by:
-
Jakob Gruber authored
This pulls both classes into a dedicated file. InstructionStream may be removed in a follow-up. Tbr: mlippautz@chromium.org Bug: v8:6666 Change-Id: Ibd374eba25cebf7495390ec13f6b4aeac5e1dc01 Reviewed-on: https://chromium-review.googlesource.com/c/1337738Reviewed-by:
Michael Lippautz <mlippautz@chromium.org> Reviewed-by:
-
v8-ci-autoroll-builder authored
Rolling v8/build: https://chromium.googlesource.com/chromium/src/build/+log/ccf9ff5..e983b53 Rolling v8/third_party/catapult: https://chromium.googlesource.com/catapult/+log/8a6451c..e69406d Rolling v8/third_party/depot_tools: https://chromium.googlesource.com/chromium/tools/depot_tools/+log/f66e551..8ada4d5 Rolling v8/tools/clang: https://chromium.googlesource.com/chromium/src/tools/clang/+log/fa8094f..b19f15a TBR=machenbach@chromium.org,hablich@chromium.org,sergiyb@chromium.org Change-Id: Id7245fc90eee541a03b16d30b337db4afb07bc7f Reviewed-on: https://chromium-review.googlesource.com/c/1339239Reviewed-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@{#57561}
-
Jakob Kummerow authored
All C++ functions called directly from generated code must have a predictable ABI. We ensure that by requiring their return and argument types to be scalars -- in particular, they must not be non-pointer ObjectPtr or ObjectSlot types, which is easy to get wrong and difficult to debug. This patch adds compile-time type checks enforcing the requirement to the macro used for creating ExternalReferences for functions. Bug: v8:3770 Change-Id: I442cf25e2f72b7ea84d4a50c9c665b187b179ca0 Reviewed-on: https://chromium-review.googlesource.com/c/1334974 Commit-Queue: Jakob Kummerow <jkummerow@chromium.org> Reviewed-by:
Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#57560}
-
Jakob Gruber authored
This reverts commit 9c91b687. Reason for revert: https://ci.chromium.org/p/v8/builders/luci.v8.ci/V8%20Arm%20GC%20Stress/8864 Original change's description: > [turbofan] Use feedback when reducing global loads/stores. > > We already record the script context location or the property cell > as feedback of the global load/store IC, so Turbofan doesn't need > to do the lookups again. > > Change-Id: I6cbd2937de344729cd8e146b4ff85ddf3de6a56e > Reviewed-on: https://chromium-review.googlesource.com/c/1335691 > Commit-Queue: Georg Neis <neis@chromium.org> > Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> > Cr-Commit-Position: refs/heads/master@{#57555} TBR=neis@chromium.org,ishell@chromium.org,bmeurer@chromium.org Change-Id: I99d72075e01348733fecdffc6b5572b96eb577b4 No-Presubmit: true No-Tree-Checks: true No-Try: true Reviewed-on: https://chromium-review.googlesource.com/c/1339860Reviewed-by:
-
Sergiy Byelozyorov authored
This is an experimental change that may help mitigate the issue. TBR=machenbach@chromium.org No-Try: true No-Tree-Checks: true Bug: chromium:893593 Change-Id: Idf15a63006c2c7ba2c31482e5103b2a0b1d64510 Reviewed-on: https://chromium-review.googlesource.com/c/1339401 Commit-Queue: Sergiy Byelozyorov <sergiyb@chromium.org> Reviewed-by:
Sergiy Byelozyorov <sergiyb@chromium.org> Cr-Commit-Position: refs/heads/master@{#57558}
-
Sergiy Byelozyorov authored
This reverts commit f1741bdd. Reason for revert: forgot to import 'time' module Original change's description: > [tools] Add retries when trying to discover the device > > This is an experimental change that may help mitigate the issue. > > TBR=machenbach@chromium.org > > No-Try: true > No-Tree-Checks: true > Bug: chromium:893593 > Change-Id: Ideb74a83b9937dbe917e8c7c93305d9824b48a93 > Reviewed-on: https://chromium-review.googlesource.com/c/1339419 > Commit-Queue: Sergiy Byelozyorov <sergiyb@chromium.org> > Reviewed-by: Sergiy Byelozyorov <sergiyb@chromium.org> > Cr-Commit-Position: refs/heads/master@{#57556} TBR=machenbach@chromium.org,sergiyb@chromium.org Change-Id: I5ae591e099f630fdb4cd63d18bfb2f1bf347f929 No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: chromium:893593 Reviewed-on: https://chromium-review.googlesource.com/c/1339519Reviewed-by:
-
Sergiy Byelozyorov authored
This is an experimental change that may help mitigate the issue. TBR=machenbach@chromium.org No-Try: true No-Tree-Checks: true Bug: chromium:893593 Change-Id: Ideb74a83b9937dbe917e8c7c93305d9824b48a93 Reviewed-on: https://chromium-review.googlesource.com/c/1339419 Commit-Queue: Sergiy Byelozyorov <sergiyb@chromium.org> Reviewed-by:
-
- 15 Nov, 2018 22 commits
-
-
Georg Neis authored
We already record the script context location or the property cell as feedback of the global load/store IC, so Turbofan doesn't need to do the lookups again. Change-Id: I6cbd2937de344729cd8e146b4ff85ddf3de6a56e Reviewed-on: https://chromium-review.googlesource.com/c/1335691 Commit-Queue: Georg Neis <neis@chromium.org> Reviewed-by:
Benedikt Meurer <bmeurer@chromium.org> Cr-Commit-Position: refs/heads/master@{#57555}
-
Predrag Rudic authored
On MIPS and MIPS64 build began to fail after this commit: 01079cb8. Change-Id: Ib967fc0d17ce1d10fdfa97d541ce9e761508593f Reviewed-on: https://chromium-review.googlesource.com/c/1337741Reviewed-by:
Ivica Bogosavljevic <ibogosavljevic@wavecomp.com> Commit-Queue: Ivica Bogosavljevic <ibogosavljevic@wavecomp.com> Cr-Commit-Position: refs/heads/master@{#57554}
-
Mathias Bynens authored
Bug: v8:7834 Change-Id: I1986c55cb884acfce11f779a23d303cd126c43d7 Reviewed-on: https://chromium-review.googlesource.com/c/1336471Reviewed-by:
Sathya Gunasekaran <gsathya@chromium.org> Commit-Queue: Mathias Bynens <mathias@chromium.org> Cr-Commit-Position: refs/heads/master@{#57553}
-
Clemens Hammacher authored
With just five cache registers, Liftoff can run out of memory on a 64bit shift. This CL solves this by using a parallel register move and pinning less registers. R=ahaas@chromium.org Bug: chromium:894307 Change-Id: I91ed0fee00ceb452841e5d1bb10905be6702dcce Reviewed-on: https://chromium-review.googlesource.com/c/1337580 Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Reviewed-by:
-
Hannes Payer authored
Change-Id: Ic9be35646beb47d0074154aa2e38dc9527911b01 Reviewed-on: https://chromium-review.googlesource.com/c/1327046 Commit-Queue: Hannes Payer <hpayer@chromium.org> Reviewed-by:
-
Andreas Haas authored
In WasmCode::LogCode we allocate handles, but not all callers of LogCode open a HandleScope. Since the handles do not escape LogCode, we can just open a Handlescope in the function. R=herhut@chromium.org Bug: v8:8461 Change-Id: I2031b467f976a9af6f541b60af245573f33d9676 Reviewed-on: https://chromium-review.googlesource.com/c/1337736Reviewed-by:
Stephan Herhut <herhut@chromium.org> Commit-Queue: Andreas Haas <ahaas@chromium.org> Cr-Commit-Position: refs/heads/master@{#57550}
-
Predrag Rudic authored
Emit Dlsa/Lsa only on revision 6 or when MSA is supported. Since we support MSA only on r6, it is the only thing that is checked. Added check if shift of Dlsa/Lsa is in range 0<shift<=31 Change-Id: Ic3902fcccc1a2e3ecc5f550ea3b7980bd2bb4c27 Reviewed-on: https://chromium-review.googlesource.com/c/1337581Reviewed-by:
-
Jakob Gruber authored
V8 supports a mechanism to generate better profiling information for ticks in bytecode execution. Usually, these would find the IET but would not know which JS function is currently being executed. With --interpreted_frames_native_stack, we create a dedicated copy of the IET for each JS function, which the profiler can use the infer the current function. This mechanism doesn't work when IET is embedded. But JIT-less V8 will require all builtins to be embedded. This CL implements a workaround that should keep all configuration happy: We keep a full copy of IET on the root list for sole purpose of using it as a template to create copies for profiling later on. The 'real' IET builtin itself can be embedded in a follow-up CL. Change-Id: Iaf1629708f0e41c3683979245019fbd3e3153c97 Reviewed-on: https://chromium-review.googlesource.com/c/1335700 Commit-Queue: Jakob Gruber <jgruber@chromium.org> Reviewed-by:
-
Peter Marshall authored
This test is only flaky because the js code being profiled causes a 'fast-c-call' which is a call from JS to C without an exit frame. The profiler stumbles on these and reads the stack of C++ frames when it shouldn't, causing ASAN errors. This is not actually related to the multiple isolates, so I'm changing the test to profile different JS code that does not cause these types of calls. There is already a test for fast-c-calls - NativeFrameStackTrace (which currently fails). Bug: v8:8464 Change-Id: I32818f0894e5680cf5a39779a2779eda36dfe9f1 Reviewed-on: https://chromium-review.googlesource.com/c/1337571 Commit-Queue: Peter Marshall <petermarshall@chromium.org> Reviewed-by:
-
Jakob Gruber authored
This is a reland of 0b13f0f5 Original change's description: > [snapshot] Emit the embedded blob as assembly instead of inline assembly > > The motivation behind this is that MSVC doesn't support inline assembly > on x64. Emitting the embedded blob as a plain assembly file will give us > MSVC support (and possibly faster compilation times as a side-effect). > > Bug: v8:6666,v8:8349 > Change-Id: I2e6cf072faa9ef406fe721a05b63912c655546c2 > Reviewed-on: https://chromium-review.googlesource.com/c/1329205 > Commit-Queue: Jakob Gruber <jgruber@chromium.org> > Reviewed-by: Michael Stanton <mvstanton@chromium.org> > Reviewed-by: Yang Guo <yangguo@chromium.org> > Cr-Commit-Position: refs/heads/master@{#57524} Tbr: yangguo@chromium.org,mvstanton@chromium.org Bug: v8:6666, v8:8349 Change-Id: Ib35696b60a9cd01bc2edf459c8e8d84716e3438d Reviewed-on: https://chromium-review.googlesource.com/c/1337733Reviewed-by:
-
Mike Stanton authored
R=mstarzinger@chromium.org Change-Id: Ifc6411f4825b5056ab35f9b7d0a604bed4004110 Reviewed-on: https://chromium-review.googlesource.com/c/1337732Reviewed-by:
-
Toon Verwaest authored
Now that we always cache lookups through scope-info-backed scopes on the entry-point scope-info-backed scope, we don't need additional caching per scope-info. The one missing piece was negative lookups, but they automatically turn into DynamicGlobals which we also cache on the entry scope. The one possible difference is that we don't cache across compilation, but seems unlikely to be very beneficial. We'll keep an eye out for regressions though. Change-Id: I23186d2b085d2042fafa32fb3cca88f88c61074c Reviewed-on: https://chromium-review.googlesource.com/c/1337731 Commit-Queue: Toon Verwaest <verwaest@chromium.org> Reviewed-by:
-
Ross McIlroy authored
With BytecodeArray flushing the SFI->BytecodeArray pointer will become pseudo weak. In order to avoid having to recompile (and potentially stack-overflow) on deoptimization, we explicitly add strong references to any BytecodeArray's we might deopt into into the DeoptimizationData, as such the BytecodeArrays won't be flushed while there is optimized code referencing it. BUG=v8:8395 Change-Id: If3336dfa9c17b7bccafdb73752c58dfa1f14a371 Reviewed-on: https://chromium-review.googlesource.com/c/1314579 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by:
-
Toon Verwaest authored
We'll always lookup variables in the entry scope-info-backed chain through a single entrypoint, hence we can cache any variables we create in that chain on the entry-point's VariableMap. Otherwise we always have to redo all negative lookups until we hit the scope that introduces it (the script scope being the final possible scope to introduce it). This should allow us to get rid of the ContextSlotCache as well. Change-Id: I2dc2c9c35d69f35dab3fe3d0353aba1ac68515a5 Reviewed-on: https://chromium-review.googlesource.com/c/1337729Reviewed-by:
Igor Sheludko <ishell@chromium.org> Commit-Queue: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#57542}
-
Georg Neis authored
This might have enabled our fuzzing to find the recent bug. R=bmeurer@chromium.org Bug: v8:8449 Change-Id: Iaa485061e132a9d20b995478dd9a642e2224f435 Reviewed-on: https://chromium-review.googlesource.com/c/1337588Reviewed-by:
-
Jakob Gruber authored
This is a reland of bf2f0a02 Original change's description: > [builtins] Support embedded builtins in nosnapshot builds > > This CL adds support for embedded builtins in nosnap builds by creating > and setting an 'embedded blob' after builtin generation. Unlike > snapshot builds, the blob is not embedded into the .text section but > located on the C++ heap. > > This makes nosnap builds more consistent with mksnapshot, and allows us > to simplify there and in serializer cctests. > > Complications arise from the different workflows we need to support: > > 1. the standard mksnapshot build process, > 2. nosnap builds (which reuse the blob created by the first Isolate), > 2. and tests with various complicated serialization workflows. > > To cover all of these cases, this CL introduces two knobs to twiddle: > > 1. A 'sticky' embedded blob which overrides compiled-in default > embedded blobs at Isolate setup. > 2. The blob lifecycle can be managed manually or through refcounting. > > These are described in more detail in isolate.cc. > > Tbr: ulan@chromium.org > Bug: v8:6666, v8:8350 > Change-Id: I3842e40cdaf45d2cadd05c6eb1ec2f5e3d83568d > Reviewed-on: https://chromium-review.googlesource.com/c/1310195 > Reviewed-by: Jakob Gruber <jgruber@chromium.org> > Reviewed-by: Yang Guo <yangguo@chromium.org> > Commit-Queue: Jakob Gruber <jgruber@chromium.org> > Cr-Commit-Position: refs/heads/master@{#57523} Tbr: ulan@chromium.org,yangguo@chromium.org Bug: v8:6666, v8:8350 Change-Id: I13b523c9e7406b39a3cd28465c06f17f1744a738 Reviewed-on: https://chromium-review.googlesource.com/c/1337578 Commit-Queue: Jakob Gruber <jgruber@chromium.org> Reviewed-by:
-
Toon Verwaest authored
Change-Id: Iee70b82742aa6399b211a5d3efe06b93c0508a7d Reviewed-on: https://chromium-review.googlesource.com/c/1337587Reviewed-by:
-
Clemens Hammacher authored
We often need to create a {Vector} view of data owned by a container like {std::vector}. The canonical way to do this is this: Vector<T>{vec.data(), vec.size()} This pattern is repeating information which can be deduced automatically, like the type T. This CL introduces a {VectorOf} helper which can construct a {Vector} for any container providing a {data()} and {size()} accessor, and uses it to replace the pattern above. R=ishell@chromium.org Bug: v8:8238 Change-Id: Ib3a11662acc82cb83f2b4afd07ba88e579d71dba Reviewed-on: https://chromium-review.googlesource.com/c/1337584Reviewed-by: -
Toon Verwaest authored
Change-Id: Id81b028629d552e2f3ebbab8bc3ab1f0e9cff3fb Reviewed-on: https://chromium-review.googlesource.com/c/1337572Reviewed-by:
-
Ross McIlroy authored
With Bytecode flushing, the a SharedFunctionInfo's bytecode might be flushed while the compiler is expecting it to still exist. Rather than continually getting the bytecode from the SFI, instead bottleneck the points where we get BytecodeArray from SFIs and maintain an explicit strong reference to the BytecodeArray from that point onwards to prevent flushing. BUG=v8:8395 Change-Id: I6a18adec99402838690971eb37ee0617cdc15920 Reviewed-on: https://chromium-review.googlesource.com/c/1309763 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by:
-
Benedikt Meurer authored
When one of the inputs to NumberMin or NumberMax is NaN we need to return NaN, ignoring whatever else was passed. Specifically we cannot lower `NumberMin(x,y)` to `(x < y) ? x : y` if `x` can be NaN. So limit this optimization to only perform the above lowering if we know that `x` is an OrderedNumber and `y` is a PlainNumber (or if the difference between zeros doesn't matter, an OrderedNumber as well). Bug: chromium:905457 Change-Id: If05f19255e14789ab0e277e072469c40e161b85b Reviewed-on: https://chromium-review.googlesource.com/c/1337576Reviewed-by:
Georg Neis <neis@chromium.org> Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Cr-Commit-Position: refs/heads/master@{#57535}
-
Michael Achenbach authored
The archive builder is broken since https://crrev.com/c/1330912, see: https://ci.chromium.org/p/v8/builders/luci.v8.ci/V8%20Official%20Win64/3279 We don't need the windows cctest on the ref builds, hence this removes it. TBR=sergiyb@chromium.org Change-Id: Ic8d40bcc45b2f29884cc3fe9a2802e2b86f099a2 Reviewed-on: https://chromium-review.googlesource.com/c/1337583Reviewed-by:
Michael Achenbach <machenbach@chromium.org> Commit-Queue: Michael Achenbach <machenbach@chromium.org> Cr-Commit-Position: refs/heads/master@{#57534}
-
