- 08 Oct, 2018 20 commits
-
-
Andreas Haas authored
R=clemensh@chromium.org bug: v8:8275 Change-Id: I4f0beb7064e1a87691e02890b5f96160b1b6c37a Reviewed-on: https://chromium-review.googlesource.com/c/1268157Reviewed-by:
Clemens Hammacher <clemensh@chromium.org> Commit-Queue: Andreas Haas <ahaas@chromium.org> Cr-Commit-Position: refs/heads/master@{#56448}
-
Daniel Clifford authored
In the process: - Convert TryLabelStatements into TryLabelExpressions - Change TryLabelExpressions to support only single label blocks and de-sugar try/labels into nested try/label statements. This allows the code in a label block to goto subsequent labels in the same try/label statement. - Make otherwise expressions either take IdentifierExpressions which get converted into simple label names OR atomarStatements, which make useful non-label operations, like 'break' and 'continue', useful together with otherwise. Non-label otherwise statements get de-sugared into try/label blocks. Bug: v8:7793 Change-Id: Ie56ede6306e2a3182f6aa1bb8750ed418bda01db Reviewed-on: https://chromium-review.googlesource.com/c/1266997 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by:
Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#56447}
-
Toon Verwaest authored
Change-Id: I33426cdbec284f3f2f8d80b29788067efc56226b Reviewed-on: https://chromium-review.googlesource.com/c/1267942Reviewed-by:
Igor Sheludko <ishell@chromium.org> Commit-Queue: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#56446}
-
Toon Verwaest authored
Always parse through ParseFunctionBody to avoid bugs with parameter/scope handling. Change-Id: Ia0e78c6b3127e99f92a6c772ba2be509f6379f5a Reviewed-on: https://chromium-review.googlesource.com/c/1268236 Commit-Queue: Toon Verwaest <verwaest@chromium.org> Reviewed-by:
Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#56445}
-
Michael Starzinger authored
This adds basic support for decoding catch-all expressions as part of a try block. Note that control flow and code generation support is still missing. R=clemensh@chromium.org TEST=unittests/FunctionBodyDecoderTest.TryCatchAll BUG=v8:8091 Change-Id: I10a1aa3e3e0418e0a04965e8318c94f449a00bb4 Reviewed-on: https://chromium-review.googlesource.com/c/1268059 Commit-Queue: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by:
-
Marja Hölttä authored
See https://chromium-review.googlesource.com/1219025 for the corresponding MaybeObject renaming. BUG=v8:7308 Change-Id: Ib454fd53d12f110da289e1d3e1e12411b016e557 Reviewed-on: https://chromium-review.googlesource.com/c/1267937Reviewed-by:
Ross McIlroy <rmcilroy@chromium.org> Reviewed-by:
-
Benedikt Meurer authored
This adds support to the escape analysis to allow scalar replacement of (small) FixedArrays with element accesses where the index is not a compile time constant. This happens quite often when inlining functions that operate on variable number of arguments. For example consider this little piece of code: ```js function sum(...args) { let s = 0; for (let i = 0; i < args.length; ++i) s += args[i]; return s; } function sum2(x, y) { return sum(x, y); } ``` This example is made up, of course, but it shows the problem. Let's assume that TurboFan inlines the function `sum` into it's call site at `sum2`. Now it has to materialize the `args` array with the two values `x` and `y`, and iterate through these `args` to sum them up. The escape analysis pass figures out that `args` doesn't escape (aka doesn't outlive) the optimized code for `sum2` now, but TurboFan still needs to materialize the elements backing store for `args` since there's a `LoadElement(args.elements,i)` in the graph now, and `i` is not a compile time constant. However the escape analysis has more information than just that. In particular the escape analysis knows exactly how many elements a non escaping object has, based on the fact that the allocation must be local to the function and that we only track objects with known size. So in the case above when we get to `args[i]` in the escape analysis the relevant part of the graph looks something like this: ``` elements = LoadField[elements](args) length = LoadField[length](args) index = CheckBounds(i, length) value = LoadElement(elements, index) ``` In particular the contract here is that `LoadElement(elements,index)` is guaranteed to have an `index` that is within the valid bounds for the `elements` (there must be a preceeding `CheckBounds` or some other guard in optimized code before it). And since `elements` is allocated inside of the optimized code object, the escape analysis also knows that `elements` has exactly two elements inside (namely the values of `x` and `y`). So we can use that information and replace the access with a `Select(index===0,x,y)` operation instead, which allows us to scalar replace the `elements`, since there's no escaping use anymore in the graph. We do this for the case that the number of elements is 2, as described above, but also for the case where elements length is one. In case of 0, we know that the `LoadElement` must be in dead code, but we can't just mark it for deletion from the graph (to make sure it doesn't block scalar replacement of non-dead code), so we don't handle this for now. And for one element it's even easier, since the `LoadElement` has to yield exactly said element. We could generalize this to handle arbitrary lengths, but since there's a cost to arbitrary decision trees here, it's unclear when this is still beneficial. Another possible solution for length > 2 would be to have special stack allocation for these backing stores and do variable index accesses to these stack areas. But that's way beyond the scope of this isolated change. This change shows a ~2% improvement on the EarleyBoyer benchmark in JetStream, since it benefits a lot from not having to materialize these small arguments backing stores. Drive-by-fix: Fix JSCreateLowering to properly initialize "elements" with StoreElement instead of StoreField (which violates the invariant in TurboFan that fields and elements never alias). Bug: v8:5267, v8:6200 Change-Id: Idd464a15a81e7c9653c48c814b406eb859841428 Reviewed-on: https://chromium-review.googlesource.com/c/1267935 Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by: -
Benedikt Meurer authored
This change adds predicates to check whether a given JavaScript operator needs the "current context" or if any surrounding context (including the "native context") does it. For example JSAdd doesn't ever need the current context, but actually only the native context. In the BytecodeGraphBuilder we use this predicate to check whether a given operator needs the current context, and if not, we just pass in the native context. Doing so we improve the performance on the benchmarks given in the tracking bug significantly, and go from something around arrayMap: 476 ms. arrayFilter: 312 ms. arrayEvery: 241 ms. arraySome: 152 ms. to arrayMap: 377 ms. arrayFilter: 296 ms. arrayEvery: 191 ms. arraySome: 91 ms. which is an up to 40% improvement. So for idiomatic modern JavaScript which uses higher order functions quite a lot, not just the builtins provided by the JSVM, this is going to improve peak performance noticably. This also makes it possible to completely eliminate all the allocations in the aliased sloppy arguments example ```js function foo(a) { return arguments.length; } ``` concretely we don't allocate the function context anymore and we also don't allocate the arguments object anymore (the JSStackCheck was the reason why we did this in the past, because it was holding on to the current context, which also kept the allocation for the arguments alive). Bug: v8:6200, v8:8060 Change-Id: I1db56d00d6b510ce6337608c0fff16af96e95eef Design-Document: bit.ly/v8-turbofan-context-sensitive-js-operators Reviewed-on: https://chromium-review.googlesource.com/c/1267176Reviewed-by:Georg Neis <neis@chromium.org> Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Cr-Commit-Position: refs/heads/master@{#56441}
-
Clemens Hammacher authored
On windows, the {NativeModule::committed_code_space_} counter can underflow because of a bug. This propagates to {WasmCodeManager::remaining_uncommitted_code_space_}, which can lead to over-allocation (more than {kMaxWasmCodeMemory} bytes of code space per module). We were also seeing this bug on UMA data (>1024 MB code space usage). R=ahaas@chromium.org Bug: chromium:893096 Change-Id: If3c9b3e7bdc9fc3caf1eccae991123409718b90f Reviewed-on: https://chromium-review.googlesource.com/c/1267943Reviewed-by:Andreas Haas <ahaas@chromium.org> Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Cr-Commit-Position: refs/heads/master@{#56440}
-
Toon Verwaest authored
This also precomputes "declares parameter containing sloppy eval" and reorders fields for better packing. Change-Id: I598ed658f79e7d83f6b844236fc60518d9cf9f26 Reviewed-on: https://chromium-review.googlesource.com/c/1267940Reviewed-by:
-
Hai Dang authored
This is a reland of ef2a19a2. Use AllocateJSArray to avoid allocating an empty fixed array. Original change's description: > Add fast path for spreading primitive strings. > > This improves the performance on primitive strings of > IterableToListWithSymbolLookup, which implements the > CreateArrayFromIterable bytecode. The fast path is only > taken if the string iterator protector is valid (that is, > String.prototype[Symbol.iterator] and > String.prototype[Symbol.iterator]().next are untouched). > > This brings spreading of primitive strings closer to the > performance of the string iterator optimizations. > (see https://docs.google.com/document/d/13z1fvRVpe_oEroplXEEX0a3WK94fhXorHjcOMsDmR-8/). > > Bug: chromium:881273, v8:7980 > Change-Id: Ic8d8619da2f2afcc9346203613a844f62653fd7a > Reviewed-on: https://chromium-review.googlesource.com/1243110 > Commit-Queue: Hai Dang <dhai@google.com> > Reviewed-by: Georg Neis <neis@chromium.org> > Reviewed-by: Ulan Degenbaev <ulan@chromium.org> > Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> > Reviewed-by: Sigurd Schneider <sigurds@chromium.org> > Cr-Commit-Position: refs/heads/master@{#56329} Bug: chromium:881273, v8:7980 Change-Id: I746c57ddfc300e1032057b5125bc824adf5c2cd3 Reviewed-on: https://chromium-review.googlesource.com/c/1267497 Commit-Queue: Georg Neis <neis@chromium.org> Reviewed-by:
Ulan Degenbaev <ulan@chromium.org> Reviewed-by:
-
Mathias Bynens authored
Bug: v8:7834 Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng Change-Id: Ie588d032136b164a2e1bcfacf3c22b1a3428f20e Reviewed-on: https://chromium-review.googlesource.com/c/1262676 Commit-Queue: Mathias Bynens <mathias@chromium.org> Reviewed-by:
Sathya Gunasekaran <gsathya@chromium.org> Cr-Commit-Position: refs/heads/master@{#56437}
-
Jaroslav Sevcik authored
Bug: chromium:893058 Change-Id: I679c5e645eda5e8e5eb97fa873d0e2ee8ce61e11 Reviewed-on: https://chromium-review.googlesource.com/c/1267938 Commit-Queue: Jaroslav Sevcik <jarin@chromium.org> Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by:
Benedikt Meurer <bmeurer@chromium.org> Cr-Commit-Position: refs/heads/master@{#56436}
-
Michael Starzinger authored
R=clemensh@chromium.org BUG=v8:8263 Change-Id: I6149cc6b353d4676a4b9170c906fe37822020217 Reviewed-on: https://chromium-review.googlesource.com/c/1267941Reviewed-by:
-
Georg Neis authored
When generating code for element accesses, we used to constant-fold JSTypedArray receivers even when their buffers were on the JS heap. This required a call to MaterializeArrayBuffer, which hinders background compilation. Since the benefit of this optimization is believed to be small, we decided to remove it. Bug: v8:7790 Change-Id: I28d3a57b3d8f5b58b6e00e0bb8328b682a6fbd88 Reviewed-on: https://chromium-review.googlesource.com/c/1256831 Commit-Queue: Georg Neis <neis@chromium.org> Reviewed-by:
-
Georg Neis authored
Return the actual length even when the buffer is neutered (we used to return 0). This avoids confusion and makes the behavior consistent with byte_offset() and byte_length(). Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng Change-Id: I998f12fa4a428f8555f62e1535247f571ab053f2 Reviewed-on: https://chromium-review.googlesource.com/c/1256768Reviewed-by:
-
Maya Lekova authored
Bug: chromium:892858 Change-Id: I97b0b239e3ee0a9073fdbd609fb26271dda64d6d Reviewed-on: https://chromium-review.googlesource.com/c/1267936 Commit-Queue: Maya Lekova <mslekova@chromium.org> Reviewed-by:
-
Jaroslav Sevcik authored
Using function ids is more reliable since there can be several functions or scripts with the same name. Also, that way we do not have to parse anything. Change-Id: If657141d0d6e27dabb49456e0275cce65e753541 Reviewed-on: https://chromium-review.googlesource.com/c/1267496Reviewed-by:
Yang Guo <yangguo@chromium.org> Commit-Queue: Jaroslav Sevcik <jarin@chromium.org> Cr-Commit-Position: refs/heads/master@{#56431}
-
Benedikt Meurer authored
In the JSCallReducer, the lowering for Array#filter(), Array#some() and Array#every() properly converted the outcome of the predicate call to boolean using the ToBoolean conversion, but then also added a redundant ReferenceEqual comparison with true. This particular pattern is not optimized by TurboFan, since it can never happen using the regular comparison machinery. So remove the unnecessary ReferenceEqual and just do the ToBoolean in the JSCallReducer. Bug: v8:8238 Change-Id: Ic2585431b4b75d3d5f978c85156cfb19738b7ae6 Reviewed-on: https://chromium-review.googlesource.com/c/1267177Reviewed-by:
Jaroslav Sevcik <jarin@chromium.org> Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Cr-Commit-Position: refs/heads/master@{#56430}
-
v8-ci-autoroll-builder authored
Rolling v8/build: https://chromium.googlesource.com/chromium/src/build/+log/86e6b5e..63f397a TBR=machenbach@chromium.org,hablich@chromium.org,sergiyb@chromium.org Change-Id: Iff11ed400b0e9440fa03f8b783e4ae4308c0166c Reviewed-on: https://chromium-review.googlesource.com/c/1267656 Commit-Queue: v8-ci-autoroll-builder <v8-ci-autoroll-builder@chops-service-accounts.iam.gserviceaccount.com> Reviewed-by:
v8-ci-autoroll-builder <v8-ci-autoroll-builder@chops-service-accounts.iam.gserviceaccount.com> Cr-Commit-Position: refs/heads/master@{#56429}
-
- 07 Oct, 2018 3 commits
-
-
Benedikt Meurer authored
As identified in the web-tooling-benchmark, there are specific code patterns involving array indexed property accesses and subsequent comparisons of those indices that lead to repeated Smi checks in the optimized code, which in turn leads to high register pressure and generally bad register allocation. An example of this pattern is code like this: ```js function f(a, n) { const i = a[n]; if (n >= 1) return i; } ``` The `a[n]` property access introduces a CheckBounds on `n`, which later lowers to a `CheckedTaggedToInt32[dont-check-minus-zero]`, however the `n >= 1` comparison has collected `SignedSmall` feedback and so it introduces a `CheckedTaggedToTaggedSigned` operation. This second Smi check is redundant and cannot easily be combined with the earlier tagged->int32 conversion, since that also deals with heap numbers and even truncates -0 to 0. So we teach the RedundancyElimination to look at the inputs of these speculative number comparisons and if there's a leading bounds check on either of these inputs, we change the input to the result of the bounds check. This avoids the redundant Smi checks later and generally allows the SimplifiedLowering to do a significantly better job on the number comparisons. We only do this in case of SignedSmall feedback and only for inputs that are not already known to be in UnsignedSmall range, to avoid doing too many (unnecessary) expensive lookups during RedundancyElimination. All of this is safe despite the fact that CheckBounds truncates -0 to 0, since the regular number comparisons in JavaScript identify 0 and -0 (unlike Object.is()). This also adds appropriate tests, especially for the interesting cases where -0 is used only after the code was optimized. Bug: v8:6936, v8:7094 Change-Id: Ie37114fb6192e941ae1a4f0bfe00e9c0a8305c07 Reviewed-on: https://chromium-review.googlesource.com/c/1246181Reviewed-by:Sigurd Schneider <sigurds@chromium.org> Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Cr-Commit-Position: refs/heads/master@{#56428}
-
Benedikt Meurer authored
This reverts commit 4fd92b25. Reason for revert: Significant tankage on the no-mitigations bots (bad timing on the regular bots) Original change's description: > [turbofan] Do not consume SignedSmall feedback in TurboFan anymore. > > This changes TurboFan to treat SignedSmall feedback similar to Signed32 > feedback for binary and compare operations, in order to simplify and > unify the machinery. > > This is an experiment. If this turns out to tank performance, we will > need to revisit and ideally revert this change. > > Bug: v8:7094 > Change-Id: I885769c2fe93d8413e59838fbe844650c848c3f1 > Reviewed-on: https://chromium-review.googlesource.com/c/1261442 > Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> > Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> > Cr-Commit-Position: refs/heads/master@{#56411} TBR=jarin@chromium.org,bmeurer@chromium.org # Not skipping CQ checks because original CL landed > 1 day ago. Bug: v8:7094 Change-Id: I9fff3b40e6dc0ceb7611b55e1ca9940089470404 Reviewed-on: https://chromium-review.googlesource.com/c/1267175Reviewed-by:
-
v8-ci-autoroll-builder authored
Rolling v8/build: https://chromium.googlesource.com/chromium/src/build/+log/a092193..86e6b5e TBR=machenbach@chromium.org,hablich@chromium.org,sergiyb@chromium.org Change-Id: I70e960aca4160188ecc4100d286110f91f013964 Reviewed-on: https://chromium-review.googlesource.com/c/1266854 Commit-Queue: v8-ci-autoroll-builder <v8-ci-autoroll-builder@chops-service-accounts.iam.gserviceaccount.com> Reviewed-by:
-
- 06 Oct, 2018 5 commits
-
-
Dimitri Glazkov authored
Add necessary dependencies and rules to produce a functional Fuchsia d8 package from a standalone V8 build. R=adamk BUG= Change-Id: If81cc9fc37822cda47bb1fe1846b9519c8fcbf40 Reviewed-on: https://chromium-review.googlesource.com/c/1226414 Commit-Queue: Dimitri Glazkov <dglazkov@chromium.org> Reviewed-by:
Adam Klein <adamk@chromium.org> Reviewed-by:
Michael Achenbach <machenbach@chromium.org> Cr-Commit-Position: refs/heads/master@{#56425}
-
Frank Tang authored
Bug: v8:6891 Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng Change-Id: I075c4f615a4366c34723104410e8445054a3cacd Reviewed-on: https://chromium-review.googlesource.com/c/1256867Reviewed-by:
Daniel Ehrenberg <littledan@chromium.org> Commit-Queue: Frank Tang <ftang@chromium.org> Cr-Commit-Position: refs/heads/master@{#56424}
-
Frank Tang authored
Use bits flag for caseFirst, hourCycle and numeric in Locale. Also set up macro for V8_INTL_SUPPORT only in heap-symbols.h Bug: v8:7684, v8:8256 Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng Change-Id: I3f6956b6dd5782e88676667381a7d8a7b2476bfc Reviewed-on: https://chromium-review.googlesource.com/c/1262476 Commit-Queue: Frank Tang <ftang@chromium.org> Reviewed-by:
-
v8-ci-autoroll-builder authored
Rolling v8/build: https://chromium.googlesource.com/chromium/src/build/+log/d36c5ed..a092193 Rolling v8/third_party/catapult: https://chromium.googlesource.com/catapult/+log/3f7d74f..4fc4281 Rolling v8/third_party/depot_tools: https://chromium.googlesource.com/chromium/tools/depot_tools/+log/8e9443f..71e3be7 TBR=machenbach@chromium.org,hablich@chromium.org,sergiyb@chromium.org Change-Id: I3ce7d9e462cd45370e42ccbb7dd22ee116fda1e8 Reviewed-on: https://chromium-review.googlesource.com/c/1266838Reviewed-by:
-
Frank Tang authored
Bug: v8:7684 Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng Change-Id: I9c727e2d8b9efad09fdf712655ea367560cd971f Reviewed-on: https://chromium-review.googlesource.com/c/1263655 Commit-Queue: Frank Tang <ftang@chromium.org> Reviewed-by:
-
- 05 Oct, 2018 12 commits
-
-
Bill Budge authored
- Exposes IsSupportedVersion function which compares serialized version to current Wasm version. - Tweaks the comments on serialization to match the code. Bug: chromium:719172 Change-Id: I76df9605aee16fd98cd82b54dba2e9acbd56b41b Reviewed-on: https://chromium-review.googlesource.com/c/1265141Reviewed-by:
Ben Smith <binji@chromium.org> Commit-Queue: Bill Budge <bbudge@chromium.org> Cr-Commit-Position: refs/heads/master@{#56420}
-
Junliang Yan authored
Drive-by: also cleanup ppc 32-bit support R=joransiu@ca.ibm.com Change-Id: I0596405ae59a0f18db7eb0f480944b8530a31113 Reviewed-on: https://chromium-review.googlesource.com/c/1262936Reviewed-by:
Joran Siu <joransiu@ca.ibm.com> Reviewed-by:
-
Alexei Filippov authored
The RNG state is initialized with random_seed parameter that usually has lots of zeros. Each random generation iteration shuffles bits with xor operation over the state. It takes a while before the state is populated with enough 1s and starts generating uniformly distributed numbers. The patch warms up the state with 32 iterations when --random_seed is used. BUG=v8:8265 Change-Id: I7a4e8c842962bea0f2935c7b3673494367d8580f Reviewed-on: https://chromium-review.googlesource.com/c/1263816 Commit-Queue: Alexei Filippov <alph@chromium.org> Reviewed-by:
-
Mathias Bynens authored
Previously, bootstrapper.cc contained a mixture of approaches: - NewStringFromAsciiChecked("foo"): 40 matches - NewStringFromStaticChars("foo"): 4 matches - InternalizeUtf8String("foo"): 55 matches The most common use case for any of these in the bootstrapper is to represent property names. For those, we eventually need internalized strings anyhow. E.g. NewStringFromAscii causes an InternalizeString call later, possibly creating a copy or ThinString. This patch uses InternalizeUtf8String where it makes sense to do so. https://chromium-review.googlesource.com/c/v8/v8/+/1253603/1/src/bootstrapper.cc#2098 Bug: v8:8238 Change-Id: I124607988b75449d7f78d5933657c35b532bd1c9 Reviewed-on: https://chromium-review.googlesource.com/c/1255727 Commit-Queue: Mathias Bynens <mathias@chromium.org> Reviewed-by:Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#56417}
-
Junliang Yan authored
This reverts commit b8a5ae47. Change-Id: If5953398586af66f827103326891f7b4b39b78d1 Reviewed-on: https://chromium-review.googlesource.com/c/1262999Reviewed-by:
-
Benedikt Meurer authored
This forces .generator_object variable to stack slot 0 for async generator functions so that the stack trace construction logic can extract the JSAsyncGeneratorObject appropriately. Bug: v8:7522 Change-Id: I37b52836bb512bcf5cd7e10e1738c8e7895b06ea Ref: nodejs/node#11865 Design-Document: http://bit.ly/v8-zero-cost-async-stack-traces Reviewed-on: https://chromium-review.googlesource.com/c/1264556Reviewed-by:
-
Maya Lekova authored
Design doc: https://docs.google.com/document/d/1kL08cz4lR6gO5b2FATNK3QAfS8t-6K6kdk88U-n8tug/edit This CL is a follow-up after the original implementation, see CL: https://chromium-review.googlesource.com/c/v8/v8/+/1106977 It includes a fix for the missing async generators optimization, as well as cleanup of the manual patching of the builtins. It also includes mjsunit test for all usages of the new behaviour. Bug: v8:8267 Change-Id: I999f341acb746c6da5216e44b68a519656fd5403 Reviewed-on: https://chromium-review.googlesource.com/c/1261124Reviewed-by:
-
Ivica Bogosavljevic authored
GCC 4.9.2 on MIPS generates a reference to OFStreamBase() d8.cc. In debug mode OFStreamBase is local to libv8_base and linking fails. Change-Id: I93bb93d03a4cc81c59f94cf2168c92557845e87d Reviewed-on: https://chromium-review.googlesource.com/c/1258903Reviewed-by:
-
Peter Marshall authored
For each intrinsic/runtime function we define in runtime.h, an inline version is automatically declared. We only ever use 24 of the inline functions. Even though we don't call the other ones, macro magic means they still take up space by existing in various arrays and tables like kIntrinsicFunctions. They also create code in switch statements. Some drive-by cleanups: - Remove the switch in NameForRuntimeId() and just use the table of runtime functions to lookup the name directly. - Remove tests for IsFunction, ClassOf and StringAdd intrinsics as they are the last users of the inline versions of these. - Remove the MaxSmi inline version as it is only used in tests. Saves 64 KiB binary size. Change-Id: I4c870ddacd2655ffcffa97d93200ed8f853752f5 Reviewed-on: https://chromium-review.googlesource.com/c/1261939 Commit-Queue: Peter Marshall <petermarshall@chromium.org> Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#56412}
-
Benedikt Meurer authored
This changes TurboFan to treat SignedSmall feedback similar to Signed32 feedback for binary and compare operations, in order to simplify and unify the machinery. This is an experiment. If this turns out to tank performance, we will need to revisit and ideally revert this change. Bug: v8:7094 Change-Id: I885769c2fe93d8413e59838fbe844650c848c3f1 Reviewed-on: https://chromium-review.googlesource.com/c/1261442Reviewed-by:
-
Toon Verwaest authored
Change-Id: I7662e9d500070a2bbe49562a9efbb459247819d5 Reviewed-on: https://chromium-review.googlesource.com/c/1264655Reviewed-by:
-
Jaroslav Sevcik authored
This cuts down the perf cost on Octane from 18% to 13%. The baseline is the no mitigation Octane score, the array access mitigation cost was about 4%. This means we would be getting a bit more than 1/3 of the poisoning regression back. Bug: chromium:856973, chromium:887213 Change-Id: Ibd99f66ae832c6080f2c2e5b33a1a7610907466f Reviewed-on: https://chromium-review.googlesource.com/c/1251401Reviewed-by:
-
