- 26 Feb, 2019 5 commits
-
-
Michael Starzinger authored
R=ahaas@chromium.org TEST=mjsunit/regress/wasm/regress-935138 BUG=chromium:935138 Change-Id: I73465e0edcdfcd33b96764ffaf5f33519e424bb8 Reviewed-on: https://chromium-review.googlesource.com/c/1486471 Commit-Queue: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by: Andreas Haas <ahaas@chromium.org> Cr-Commit-Position: refs/heads/master@{#59852}
-
Michael Achenbach authored
NOTRY=true TBR=sergiyb@chromium.org Bug: chromium:933093 Change-Id: I48236ef06c990526b72be418773d0a098c85178f Reviewed-on: https://chromium-review.googlesource.com/c/1488754Reviewed-by: Michael Achenbach <machenbach@chromium.org> Commit-Queue: Michael Achenbach <machenbach@chromium.org> Cr-Commit-Position: refs/heads/master@{#59851}
-
Georg Neis authored
Change-Id: I2d5b54c88bece3e22c4ae25d7fba094647f64f52 Reviewed-on: https://chromium-review.googlesource.com/c/1487051Reviewed-by: Maya Lekova <mslekova@chromium.org> Commit-Queue: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#59850}
-
Matt Gardner authored
MSVC 14.x and 15.x handle -0 correctly unless /fp:fast is used. /fp:precise is the default. bug: v8:3477, v8:8912 Change-Id: I242a1dfd845f750cab7c56f13107612259d44d23 Reviewed-on: https://chromium-review.googlesource.com/c/1487414Reviewed-by: Sigurd Schneider <sigurds@chromium.org> Reviewed-by: Yang Guo <yangguo@chromium.org> Commit-Queue: Yang Guo <yangguo@chromium.org> Cr-Commit-Position: refs/heads/master@{#59849}
-
Simon Zünd authored
This CL contains a basic Json parser used to read and write the Json-RPC messages of the language server protocol. This CL is part of the initial language server implementation but submitted separately for easier review. R=tebbi@chromium.org Bug: v8:8880 Change-Id: Icea040975e1ed1d587954c3342d8d876e01c26b8 Reviewed-on: https://chromium-review.googlesource.com/c/1479956 Commit-Queue: Simon Zünd <szuend@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#59848}
-
- 25 Feb, 2019 35 commits
-
-
Caitlin Potter authored
Turns --harmony-hashbang on by default. Intent to ship: https://groups.google.com/d/msg/v8-dev/hlCVa_XZ3TM/UWjjyOq3FwAJ ChromeStatus page: https://www.chromestatus.com/feature/5134505706782720 BUG=v8:8523 R=gsathya@chromium.org, mathias@chromium.org, adamk@chromium.org Change-Id: I821f69e45eb0a63a3f49181e2b88b0bcd091af2c Reviewed-on: https://chromium-review.googlesource.com/c/1486113Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Mathias Bynens <mathias@chromium.org> Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org> Commit-Queue: Caitlin Potter <caitp@igalia.com> Cr-Commit-Position: refs/heads/master@{#59847}
-
Z Duong Nguyen-Huu authored
currently it cannot call run-tests.py since it use Linux path Change-Id: I15af9c7e6503e6d473611a24f5f223ff68b1dbbd Reviewed-on: https://chromium-review.googlesource.com/c/1484110Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> Commit-Queue: Z Nguyen-Huu <duongn@microsoft.com> Cr-Commit-Position: refs/heads/master@{#59846}
-
Frank Tang authored
This is a reland of f1b21a10 Original change's description: > [Intl] Ship Intl.Locale > > Bug: v8:7684 > Change-Id: I5994c3fc4b97c4322c4e0cf20305da75e66efd5a > Reviewed-on: https://chromium-review.googlesource.com/c/1478220 > Reviewed-by: Adam Klein <adamk@chromium.org> > Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org> > Commit-Queue: Frank Tang <ftang@chromium.org> > Cr-Commit-Position: refs/heads/master@{#59780} Bug: v8:7684 Change-Id: I4f73205398a9649e2f55a1b090cd3afffade68c4 Reviewed-on: https://chromium-review.googlesource.com/c/1480918Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org> Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org> Cr-Commit-Position: refs/heads/master@{#59845}
-
Z Duong Nguyen-Huu authored
Bug: v8:6831 Change-Id: I6e9f6fc718928f2f86d3b3c2dd144a6636b05790 Reviewed-on: https://chromium-review.googlesource.com/c/1481895 Commit-Queue: Z Nguyen-Huu <duongn@microsoft.com> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Reviewed-by: Simon Zünd <szuend@chromium.org> Cr-Commit-Position: refs/heads/master@{#59844}
-
Matt Gardner authored
This change implements optimizations for the `in` operator for packed array elements and object properties. It adds a new feedback slot kind and an IC path similar to KeyedLoadIC for handling the lookups. TurboFan uses the feedback to optimize based on the maps and keys. For more details see: https://docs.google.com/document/d/1tIfzywY8AeNVcy_sen-5Xev21MeZwjcU8QhSdzHvXig This can provide 10x performance improvements of on loops of the form: for (let i = 0; i < ary.length; ++i) { if (i in ary) { ... } } Bug: v8:8733 Change-Id: I766bf865a547a059e5bce5399bb6112e5d9a85c8 Reviewed-on: https://chromium-review.googlesource.com/c/1432598Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Reviewed-by: Igor Sheludko <ishell@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Commit-Queue: Matt Gardner <magardn@microsoft.com> Cr-Commit-Position: refs/heads/master@{#59843}
-
Ulan Degenbaev authored
This prevents accumulation of non-regular chunks if unmapper tasks are not making progress. Bug: chromium:934453 Change-Id: I552bc4f566f4be8877d9e806cca2aa9c284a7f4f Reviewed-on: https://chromium-review.googlesource.com/c/1483055Reviewed-by: Michael Lippautz <mlippautz@chromium.org> Commit-Queue: Ulan Degenbaev <ulan@chromium.org> Cr-Commit-Position: refs/heads/master@{#59842}
-
Mike Stanton authored
A custom deoptimization continuation point erroneously cast a parameter to a number. Tests added. BUG: v8:7672 Change-Id: I59848aacdedc1de9fd7d83d55045618f37d39fb0 Reviewed-on: https://chromium-review.googlesource.com/c/1485974Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Commit-Queue: Michael Stanton <mvstanton@chromium.org> Cr-Commit-Position: refs/heads/master@{#59841}
-
Michael Lippautz authored
Embedders should use EmbedderHeapTracer::RegisterEmbedderReference instead. Bug: chromium:923361 Change-Id: If76c0354475798b09af95bedee0890594b29cd14 Reviewed-on: https://chromium-review.googlesource.com/c/1486472Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Commit-Queue: Michael Lippautz <mlippautz@chromium.org> Cr-Commit-Position: refs/heads/master@{#59840}
-
Jakob Gruber authored
This is a quirk needed for the regexp fuzzer, which passes its own custom RegExpMatchInfo object to RegExpImpl::Exec and expects execution without side effects. Bug: chromium:934621 Change-Id: I90286fda06593d7c574d8d4629481ebad2fa5b1d Reviewed-on: https://chromium-review.googlesource.com/c/1485833Reviewed-by: Peter Marshall <petermarshall@chromium.org> Commit-Queue: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#59839}
-
Ulan Degenbaev authored
This fixes the case of accumulating large pages after scavenges if there is no mark-compact GC. Bug: chromium:934453 Change-Id: Ide57c64ae985cc79ad9f477a759ab729f894c73b Reviewed-on: https://chromium-review.googlesource.com/c/1482740Reviewed-by: Michael Lippautz <mlippautz@chromium.org> Commit-Queue: Ulan Degenbaev <ulan@chromium.org> Cr-Commit-Position: refs/heads/master@{#59838}
-
Junliang Yan authored
Port 591408cb Original Commit Message: We'll need one bit in the SharedFunctionInfo::flags to record whether it's safe to skip arguments adaptor frames (for v8:8895), so this just removes the SharedFunctionInfo::IsDerivedConstructorBit which is redundant, since the same information is already available in the SharedFunctionInfo::FunctionKindBits, and most places in the code use that already, with the exception of the JSConstructStubGeneric builtin. This changes the JSConstructStubGeneric builtin to just check the function kind instead of testing the explicit bit, which also makes this more consistent. It seems like there's not much overhead to that, doing an additional bitmasking plus two comparisons instead of one. This shouldn't really matter since invocation and execution of the constructors is going to dominate and optimized code inlines all of this anyways. If this turns out to affect performance, we can still look into encoding the FunctionKindBits more cleverly. the shift when accessing the function kind. This seems logic, since for the actual boolean bit fields it doesn't matter where they are in the flags, whereas for the function kind this saves one shift. R=bmeurer@chromium.org, joransiu@ca.ibm.com, michael_dawson@ca.ibm.com, miladfar@ca.ibm.com BUG= LOG=N Change-Id: I4e3ba5a066285bf50e869c32228d79d26d57258f Reviewed-on: https://chromium-review.googlesource.com/c/1486411Reviewed-by: Milad Farazmand <miladfar@ca.ibm.com> Commit-Queue: Junliang Yan <jyan@ca.ibm.com> Cr-Commit-Position: refs/heads/master@{#59837}
-
Pierre Langlois authored
When calling the `bitmap(chunk)` method of the various *MarkingState accessors we would receive a raw `Bitmap` pointer which does not tell you if accesses to markbits should be made atomically or not. As a result, we would default to doing atomic operation when in fact it may not be necessary. Here we're introducing a templated `ConcurrentBitmap` class that wraps operations done on the markbits and allows them to be made non-atomic. Additionaly, some of the `Bitmap` methods were only used to verify the heap and in the tests so they do not need atomic implementations. Using them in a concurrent context should now fail to link to make sure they're not mis-used in the future. Change-Id: Ifb55f8522c8bf0c87d65da9227864ee428d21bbd Cq-Include-Trybots: luci.v8.try:v8_linux64_tsan_rel Reviewed-on: https://chromium-review.googlesource.com/c/1482916Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Commit-Queue: Pierre Langlois <pierre.langlois@arm.com> Cr-Commit-Position: refs/heads/master@{#59836}
-
Mike Stanton authored
This CL reduces the instruction size of Array.prototype.every and some by ~20%. Should performance allow it we could do the same for other array builtins. We attach a boolean to the FastJSArrayWitness that remembers if it's dealing with a FixedArray or a FixedDoubleArray. We have to check this in the loop, but it is likely that reduced code size more than pays for the extra check, since the loop will be dominated by the call to the users callback function. BUG: v8:7672 Change-Id: Id3bab2b163d7ba73424250d8bb194712909cd37e Reviewed-on: https://chromium-review.googlesource.com/c/1484293Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Commit-Queue: Michael Stanton <mvstanton@chromium.org> Cr-Commit-Position: refs/heads/master@{#59835}
-
Georg Neis authored
This was a pair of a set of maps and their common instance type (if any), but the instance type field was only used in a printing function. Removing the whole class in favor of ZoneHandleSet<Map> means we avoid looking at the heap to determine the common instance type. Eventually we can use the broker to do this if we need to. Bug: v8:7790 Change-Id: If0cadf9b17e3b9e77cffc4f0b69e2585aff7c85c Reviewed-on: https://chromium-review.googlesource.com/c/1481214Reviewed-by: Maya Lekova <mslekova@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Commit-Queue: Jaroslav Sevcik <jarin@chromium.org> Cr-Commit-Position: refs/heads/master@{#59834}
-
Tobias Tebbi authored
Since our allocations don't guarantee more than kTaggedSize alignment, it doesn't make sense to warn about mis-alignment beyond that. Bug: v8:8863 v8:7793 Change-Id: Ia1c2dd25efdb2c1084968ab4ffe8de25b8654cdb Reviewed-on: https://chromium-review.googlesource.com/c/1486251Reviewed-by: Igor Sheludko <ishell@chromium.org> Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#59833}
-
Peter Marshall authored
This has been marked as flaky for a long time but was fixed by https://chromium-review.googlesource.com/c/v8/v8/+/1480378. Bug: v8:5193 Change-Id: I5f03f028fd006bcc83407b48ed49289c5573cade Reviewed-on: https://chromium-review.googlesource.com/c/1476993Reviewed-by: Yang Guo <yangguo@chromium.org> Commit-Queue: Peter Marshall <petermarshall@chromium.org> Cr-Commit-Position: refs/heads/master@{#59832}
-
Ross McIlroy authored
With stress bytecode flushing it's possible for the main SFI of a script to have it's bytecode flushed during deserialization of the script. If this happens, just fall-through to recompile the SFI. BUG=v8:8901,v8:8395 Change-Id: I786c1ca93167b76810481892ade525d14ff9168f Reviewed-on: https://chromium-review.googlesource.com/c/1485837Reviewed-by: Mythri Alle <mythria@chromium.org> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#59831}
-
Benedikt Meurer authored
Mark the not_ok case as deferred. Bug: v8:8834 Change-Id: I17536e45fb6aa309347b8faaf5f25fb3bbfbf6cf Reviewed-on: https://chromium-review.googlesource.com/c/1485973Reviewed-by: Yang Guo <yangguo@chromium.org> Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Cr-Commit-Position: refs/heads/master@{#59830}
-
Benedikt Meurer authored
Add some additional safety net to the CSA code for triggering promise reactions to make sure we catch security bugs (specifically related to misuse of the V8 Extras API) on the fast-path. Bug: chromium:931640, chromium:931949 Change-Id: I76b5dc6653e2404411a29dcd9c54245d7c43d883 Reviewed-on: https://chromium-review.googlesource.com/c/1485972Reviewed-by: Yang Guo <yangguo@chromium.org> Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Cr-Commit-Position: refs/heads/master@{#59829}
-
Sigurd Schneider authored
This reverts commit b3d8eeb6. Reason for revert: https://ci.chromium.org/p/chromium/builders/luci.chromium.try/win7-rel/25961 Original change's description: > [Torque] Port Array.prototype.reduce and reduceRight to Torque > > BUG: v8:7672 > Change-Id: I8816ab9051e7900119fd65c239f9e207f5c3d417 > Reviewed-on: https://chromium-review.googlesource.com/c/1478697 > Commit-Queue: Michael Stanton <mvstanton@chromium.org> > Reviewed-by: Tobias Tebbi <tebbi@chromium.org> > Cr-Commit-Position: refs/heads/master@{#59807} TBR=mvstanton@chromium.org,tebbi@chromium.org # Not skipping CQ checks because original CL landed > 1 day ago. Change-Id: Ib15bd4499618a22185d8ef173c4df7b7d55f54ce Reviewed-on: https://chromium-review.googlesource.com/c/1485971Reviewed-by: Sigurd Schneider <sigurds@chromium.org> Reviewed-by: Michael Stanton <mvstanton@chromium.org> Commit-Queue: Michael Stanton <mvstanton@chromium.org> Cr-Commit-Position: refs/heads/master@{#59828}
-
Toon Verwaest authored
All uses of ParseMemberExpression go through ParseMemberWithNewPrefixesExpression, and ParseMemberExpression always starts with ParsePrimaryExprssion, so we can simply move Token::NEW handling into ParsePrimaryExpression. That avoids an unnecessary branch on the hot path. Change-Id: I2bcce8e106c547c6d308ee6b0fce8747c7214886 Reviewed-on: https://chromium-review.googlesource.com/c/1485838Reviewed-by: Leszek Swirski <leszeks@chromium.org> Commit-Queue: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#59827}
-
Toon Verwaest authored
This saves some binary size. Change-Id: I64d20be63922ba0aab0b664fb30c3e2e023bb860 Reviewed-on: https://chromium-review.googlesource.com/c/1485841 Commit-Queue: Toon Verwaest <verwaest@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#59826}
-
Benedikt Meurer authored
When calling a known function from optimized code, where the number of actual arguments does not match the number of expected arguments, TurboFan has to call indirectly via the arguments adaptor trampoline, which creates an argument adaptor frame underneath the activation record for the callee. This is done so that the callee can still get to the actual arguments, using either 1. the arguments object, or 2. rest parameters (to get to superfluous arguments), or 3. the non-standard Function.arguments accessor (for sloppy mode functions), or 4. direct eval(), where we don't know whether there's a use of the arguments object hiding somewhere in the string. However going through the arguments adaptor trampoline is quite expensive usually, it seems to be responsible for over 60% of the call overhead in those cases. So this adds a fast path for the case of calling strict mode functions where we have an arguments mismatch, but where we are sure that the callee cannot observe the actual arguments. We use a bit on the SharedFunctionInfo to indicate that this is safe, which is controlled by hints from the Parser which knows whether the callee uses either arguments object or rest parameters. In those cases we use a direct call from optimized code, passing the expected arguments instead of the actual arguments. This improves the benchmark on the document below by around 60-65%, which is exactly the overhead of the arguments adaptor trampoline that we save in this case. This also adds a runtime flag --fast_calls_with_arguments_mismatches, which can be used to turn off the new behavior. This might be handy for checking the performance impact via Finch. Bug: v8:8895 Change-Id: Idea51dba7ee6cb989e86e0742eaf3516e5afe3c4 Cq-Include-Trybots: luci.chromium.try:linux-blink-rel Doc: http://bit.ly/v8-faster-calls-with-arguments-mismatch Reviewed-on: https://chromium-review.googlesource.com/c/1482735 Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#59825}
-
Mike Stanton authored
We don't need dynamic allocation for these arrays. Change-Id: I12095ec0e3b6e9d70be56adfb77aded5c25eb3d5 Reviewed-on: https://chromium-review.googlesource.com/c/908462 Commit-Queue: Michael Stanton <mvstanton@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Reviewed-by: Peter Marshall <petermarshall@chromium.org> Cr-Commit-Position: refs/heads/master@{#59824}
-
Maciej Goszczycki authored
This means ReadOnlyDeserializer can be made isolate independent. Without this Isolate is needed for rehashing read-only space. Bug: v8:7464 Change-Id: Id2c9968a0ecfa2362f499ded6c7e0f7b2be00dfb Reviewed-on: https://chromium-review.googlesource.com/c/1483054 Commit-Queue: Maciej Goszczycki <goszczycki@google.com> Reviewed-by: Dan Elphick <delphick@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#59823}
-
Sigurd Schneider authored
This removes ast.h as include from about ~500 includers of the latter. Bug: v8:8834 Change-Id: I294026d4bb29b878820d43c117b04a9645a457ae Reviewed-on: https://chromium-review.googlesource.com/c/1485835Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Commit-Queue: Sigurd Schneider <sigurds@chromium.org> Cr-Commit-Position: refs/heads/master@{#59822}
-
Benedikt Meurer authored
We'll need one bit in the SharedFunctionInfo::flags to record whether it's safe to skip arguments adaptor frames (for v8:8895), so this just removes the SharedFunctionInfo::IsDerivedConstructorBit which is redundant, since the same information is already available in the SharedFunctionInfo::FunctionKindBits, and most places in the code use that already, with the exception of the JSConstructStubGeneric builtin. This changes the JSConstructStubGeneric builtin to just check the function kind instead of testing the explicit bit, which also makes this more consistent. It seems like there's not much overhead to that, doing an additional bitmasking plus two comparisons instead of one. This shouldn't really matter since invocation and execution of the constructors is going to dominate and optimized code inlines all of this anyways. If this turns out to affect performance, we can still look into encoding the FunctionKindBits more cleverly. Drive-by-fix: Move the FunctionKindBits first in the flags to avoid the shift when accessing the function kind. This seems logic, since for the actual boolean bit fields it doesn't matter where they are in the flags, whereas for the function kind this saves one shift. Bug: v8:8834, v8:8895 Change-Id: I184a8f5cc5c140bdc272cf9a5ad546093c457306 Reviewed-on: https://chromium-review.googlesource.com/c/1482915Reviewed-by: Toon Verwaest <verwaest@chromium.org> Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Cr-Commit-Position: refs/heads/master@{#59821}
-
Jakob Gruber authored
Field representation tracking is only used by TurboFan. Bug: v8:7777 Change-Id: I0d930f8dc0b68ff030111f12092b183c4c257ac6 Reviewed-on: https://chromium-review.googlesource.com/c/1481218 Commit-Queue: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Igor Sheludko <ishell@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#59820}
-
Santiago Aboy Solanes authored
since these operators don't have any variable arguments. Bug: v8:8183 Change-Id: I602fe65a2137d6ffc6ece702da53d660577eee4a Reviewed-on: https://chromium-review.googlesource.com/c/1482736Reviewed-by: Sigurd Schneider <sigurds@chromium.org> Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org> Cr-Commit-Position: refs/heads/master@{#59819}
-
Ross McIlroy authored
Template objects should be cached after they are first created and reused on subsiquent calls to tag functions. Currently these cached objects are stored on the feedback vector, which has appropriate lifetime, however with bytecode flushing the feedback vector could be cleared when the bytecode is flushed, causing the template object to be dropped. In order to retain the cached template objects in the face of bytecode flushing, this CL adds a weakmap for each native context that is (weakly) keyed by shared function info, and holds a linked list of cached template objects associated with that shared function info, indexed by feedback vector slot id. Misses will check this weakmap, and if no entry is found, a new template object is created and added into this weakmap alongside the feedback vector. BUG=v8:8799,v8:8799,v8:8395 Change-Id: Ia95d5cfc394ce58dc9fe6a1e49780f05299acc17 Reviewed-on: https://chromium-review.googlesource.com/c/1477746 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Cr-Commit-Position: refs/heads/master@{#59818}
-
Jon Kunkee authored
When stubbing out source line information emission for Windows, the ARM64 Windows branch was missed. This change copies the x86/x64 stubs as appropriate. Bug: chromium:893460,v8:8870 R=jgruber@chromium.org Bug: chromium:893460,v8:8870 Change-Id: I1416b602a4f96a68c37fdeeb816ce1ce33b12407 Reviewed-on: https://chromium-review.googlesource.com/c/1453637 Commit-Queue: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Michael Stanton <mvstanton@chromium.org> Cr-Commit-Position: refs/heads/master@{#59817}
-
Tobias Tebbi authored
Bug: v8:8863 Change-Id: I8907b7b0b7dfa53a2e1e607c0bad26939d312f4e Reviewed-on: https://chromium-review.googlesource.com/c/1485836Reviewed-by: Sigurd Schneider <sigurds@chromium.org> Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#59816}
-
Jakob Gruber authored
to IsGeneratingEmbeddedBuiltins() to clarify its meaning. Bug: v8:6666 Change-Id: I8b282f29775a103a03f502c3e9629b40b4a690bd Reviewed-on: https://chromium-review.googlesource.com/c/1480380Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Commit-Queue: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#59815}
-
Toon Verwaest authored
This merges all the possible targets for 'member expressions' previously parsed in ParseMemberExpression into ParsePrimaryExpression; since that's not independently used anyway. This will make it faster since we don't need to go through unnecessary branches before ParsePrimaryExpression on the fast path, *and* it will make the binary smaller since ParseMemberExpression is inlined but ParsePrimaryExpression is not. It saves 4kb. Yay :) Bug: chromium:913222 Change-Id: Ib92e1c2a128fffff1db85b625bb5f311ec8c24ef Reviewed-on: https://chromium-review.googlesource.com/c/1480379 Commit-Queue: Toon Verwaest <verwaest@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#59814}
-
Toon Verwaest authored
That way we can continue running in failure mode. Bug: chromium:933214 Change-Id: I975901a72f615e2b7ed9955b75ce86bbcad0bbbb Reviewed-on: https://chromium-review.googlesource.com/c/1481219Reviewed-by: Leszek Swirski <leszeks@chromium.org> Commit-Queue: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#59813}
-