- 28 Feb, 2018 16 commits
-
-
Mathias Bynens authored
This brings us closer to our goal of deprecating the `construct_stub` field in `SharedFunctionInfo`. Bug: v8:7503 Change-Id: I9502246f5e463e487a989ab7f8c96c008f0fa9d9 Reviewed-on: https://chromium-review.googlesource.com/941143 Commit-Queue: Mathias Bynens <mathias@chromium.org> Reviewed-by:
Benedikt Meurer <bmeurer@chromium.org> Cr-Commit-Position: refs/heads/master@{#51634}
-
Mathias Bynens authored
This brings us closer to our goal of deprecating the `construct_stub` field in `SharedFunctionInfo`. Bug: v8:7503 Change-Id: Id7bee0d61830f7bcf2cad4f6e50ff9f24b58a51b Reviewed-on: https://chromium-review.googlesource.com/939790Reviewed-by:
-
Andreas Haas authored
R=clemensh@chromium.org Change-Id: Ib6f0c0de813049192ea99b194d5ef4b17d44cd72 Reviewed-on: https://chromium-review.googlesource.com/939784Reviewed-by:
Clemens Hammacher <clemensh@chromium.org> Commit-Queue: Andreas Haas <ahaas@chromium.org> Cr-Commit-Position: refs/heads/master@{#51632}
-
Sigurd Schneider authored
This CL also reorganizes the Strings test suite Bug: v8:7340 Change-Id: I54d4d76a16c362e38ebfc9719ac8cb1a490ef3cc Reviewed-on: https://chromium-review.googlesource.com/941122Reviewed-by:
-
Benedikt Meurer authored
Next step on deprecating the construct_stub field in the SharedFunctionInfo. Bug: v8:7503 Change-Id: Ibcbf9dc0dbcbcf0e26c103167e8a30074cbdd888 Reviewed-on: https://chromium-review.googlesource.com/940942Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Cr-Commit-Position: refs/heads/master@{#51630}
-
Mathias Bynens authored
This brings us closer to our goal of deprecating the `construct_stub` field in `SharedFunctionInfo`. Bug: v8:7503 Change-Id: I0e995e6ed9e7c04990f76dd8fe8afaaa8d38294b Reviewed-on: https://chromium-review.googlesource.com/940124 Commit-Queue: Mathias Bynens <mathias@chromium.org> Reviewed-by:
-
Sigurd Schneider authored
Bug: v8:7250, v8:7340 Change-Id: I6267787d297b0aab698b8b38d475f6eff61a730f Reviewed-on: https://chromium-review.googlesource.com/921523Reviewed-by:
-
Mathias Bynens authored
This brings us closer to our goal of deprecating the `construct_stub` field in `SharedFunctionInfo`. Bug: v8:7503 Change-Id: I215539fb8ac52fd437d3c04a02ecba2cd38cd101 Reviewed-on: https://chromium-review.googlesource.com/940125Reviewed-by:
-
Mathias Bynens authored
This brings us closer to our goal of deprecating the `construct_stub` field in `SharedFunctionInfo`. Bug: v8:7503 Change-Id: I20e6c7d58e7cdcc7316e35568357a4ad3059a892 Reviewed-on: https://chromium-review.googlesource.com/940129Reviewed-by:
-
Benedikt Meurer authored
This is the first step on the way to eventually get rid of the construct_stub field in SharedFunctionInfos. Bug: v8:7503 Change-Id: Ib14627613851c7f2a5ab795c642bb74176285863 Reviewed-on: https://chromium-review.googlesource.com/940222Reviewed-by:
-
Sigurd Schneider authored
Bug: v8:7250, v8:7340 Change-Id: Ice54ee684f77a575d7479f4e7d4fdb55e7427da9 Reviewed-on: https://chromium-review.googlesource.com/919164 Commit-Queue: Sigurd Schneider <sigurds@chromium.org> Reviewed-by:
-
Clemens Hammacher authored
If memory is statically known to be out of bounds, do not generate code for the load or store, and also mark the rest of the current block unreachable to avoid unnecessary code generation. This also prevents us from having to special-case illegal memory offsets in the LiftoffAssembler. For valid code, the offset will always be smaller than 2GB. R=ahaas@chromium.org Bug: v8:6600 Change-Id: Ib5a9006780098e9f2ab9eda4bac7939f15612ae0 Reviewed-on: https://chromium-review.googlesource.com/939821Reviewed-by:
Andreas Haas <ahaas@chromium.org> Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Cr-Commit-Position: refs/heads/master@{#51623}
-
Clemens Hammacher authored
According to the spec, exported wasm functions should not have a [[Construct]] method, hence they don't have a prototype. R=bmeurer@chromium.org CC=titzer@chromium.org Bug: v8:7503 Change-Id: I9e142d65a80c0ef6dbd743421771f194c2d50614 Reviewed-on: https://chromium-review.googlesource.com/939782Reviewed-by:
-
Junliang Yan authored
Port be4cd67c Original Commit Message: This adds support for poisoning the stack pointer and implicit register arguments like the context register and the function register in the prologue of generated code with JavaScript linkage. The speculation poison is computed similarly to the interpreter by matching expected with actual code start addresses. R=mstarzinger@chromium.org, joransiu@ca.ibm.com, michael_dawson@ca.ibm.com BUG=chromium:798964 LOG=N Change-Id: I0d015fd8a8f05982d947a4a1c0be1a825ac19d64 Reviewed-on: https://chromium-review.googlesource.com/940460Reviewed-by:
Joran Siu <joransiu@ca.ibm.com> Commit-Queue: Junliang Yan <jyan@ca.ibm.com> Cr-Commit-Position: refs/heads/master@{#51621}
-
Junliang Yan authored
Port 5586ecfc Original Commit Message: This decouples the checking of the {kJavaScriptCallCodeStartRegister} from the deoptimization checks. We now rely more heavily on the above register and should check its validity more broadly. Note that there also is a bug fix for the ARM port contained in this change. R=mstarzinger@chromium.org, joransiu@ca.ibm.com, michael_dawson@ca.ibm.com BUG= LOG=N Change-Id: Ic8b58994b083c6c0ec73173120cedf6391b1c964 Reviewed-on: https://chromium-review.googlesource.com/938522Reviewed-by:
-
Junliang Yan authored
This is a reland of 89737c5d. Original change's description: > PPC/s390: [turbofan] Ensure instruction start is in fixed register. > > Port c462ddc8 > > Original Commit Message: > > This makes sure that {JSFunction} invocations always load the code start > address into the fixed {kJavaScriptCallCodeStartRegister} register. This > allows us to perform PC-relative operations more effective. For now this > only applies to code with {kCallJSFunction} linkage. > > R=mstarzinger@chromium.org, joransiu@ca.ibm.com, michael_dawson@ca.ibm.com > BUG= > LOG=N > > Change-Id: If346a3cbaea820b1fcec38c5105605496961a888 > Reviewed-on: https://chromium-review.googlesource.com/938721 > Reviewed-by: Joran Siu <joransiu@ca.ibm.com> > Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> > Commit-Queue: Junliang Yan <jyan@ca.ibm.com> > Cr-Commit-Position: refs/heads/master@{#51608} Change-Id: I5b118c3903847cc13e2ce228e9713f8ae55ce193 Reviewed-on: https://chromium-review.googlesource.com/940342Reviewed-by:
-
- 27 Feb, 2018 24 commits
-
-
Michael Achenbach authored
TBR=iannucci@chromium.org NOTRY=true Change-Id: I6bee8db469b43a01402798953a1bcdaf3dc06cf7 Reviewed-on: https://chromium-review.googlesource.com/940421 Commit-Queue: Michael Achenbach <machenbach@chromium.org> Reviewed-by:
Michael Achenbach <machenbach@chromium.org> Cr-Commit-Position: refs/heads/master@{#51618}
-
Junliang Yan authored
This reverts commit 89737c5d. Reason for revert: Sorry, missed the portion in code-generator Original change's description: > PPC/s390: [turbofan] Ensure instruction start is in fixed register. > > Port c462ddc8 > > Original Commit Message: > > This makes sure that {JSFunction} invocations always load the code start > address into the fixed {kJavaScriptCallCodeStartRegister} register. This > allows us to perform PC-relative operations more effective. For now this > only applies to code with {kCallJSFunction} linkage. > > R=mstarzinger@chromium.org, joransiu@ca.ibm.com, michael_dawson@ca.ibm.com > BUG= > LOG=N > > Change-Id: If346a3cbaea820b1fcec38c5105605496961a888 > Reviewed-on: https://chromium-review.googlesource.com/938721 > Reviewed-by: Joran Siu <joransiu@ca.ibm.com> > Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> > Commit-Queue: Junliang Yan <jyan@ca.ibm.com> > Cr-Commit-Position: refs/heads/master@{#51608} TBR=mstarzinger@chromium.org,michael_dawson@ca.ibm.com,jyan@ca.ibm.com,joransiu@ca.ibm.com Change-Id: I9a0810aa35ff39651397055ab53d250c2f6f09e0 No-Presubmit: true No-Tree-Checks: true No-Try: true Reviewed-on: https://chromium-review.googlesource.com/940341Reviewed-by:
Junliang Yan <jyan@ca.ibm.com> Commit-Queue: Junliang Yan <jyan@ca.ibm.com> Cr-Commit-Position: refs/heads/master@{#51617}
-
Eric Holk authored
This also adds a DCHECK that the buffer does not have guard pages in MaterializeArrayBuffer because the code there does not know how correctly set up a buffer with guard pages. Bug: chromium:801849 Change-Id: Ic761fcdfbd16a2d6e87f4eb135f5d03b7aa2d71d Reviewed-on: https://chromium-review.googlesource.com/938968Reviewed-by:
Deepti Gandluri <gdeepti@chromium.org> Commit-Queue: Eric Holk <eholk@chromium.org> Cr-Commit-Position: refs/heads/master@{#51616}
-
Michael Achenbach authored
NOTRY=true TBR=sergiyb@chromium.org Change-Id: Ic67a1cc7e58143df6fc0d8c2199578007e0e960b Reviewed-on: https://chromium-review.googlesource.com/939874 Commit-Queue: Michael Achenbach <machenbach@chromium.org> Reviewed-by:
-
Michael Achenbach authored
This reverts commit 01db326c. Reason for revert: https://build.chromium.org/p/client.v8/builders/V8%20Win64%20-%20msvc/builds/1607 Original change's description: > [Assembler][x64] Make immediates immutable > > On x64, we already pass immediates by value. This CL ensures that this > is indeed cheap, and it makes immediates immutable. > > R=mstarzinger@chromium.org > > Bug: v8:7310 > Change-Id: I53a0666d53b9de69d390621298798c03b5190497 > Reviewed-on: https://chromium-review.googlesource.com/934341 > Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> > Commit-Queue: Clemens Hammacher <clemensh@chromium.org> > Cr-Commit-Position: refs/heads/master@{#51613} TBR=mstarzinger@chromium.org,clemensh@chromium.org Change-Id: Id3870e671c106644b62353c2b6c0ec2607596166 No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: v8:7310 Reviewed-on: https://chromium-review.googlesource.com/939901Reviewed-by:
-
Clemens Hammacher authored
On x64, we already pass immediates by value. This CL ensures that this is indeed cheap, and it makes immediates immutable. R=mstarzinger@chromium.org Bug: v8:7310 Change-Id: I53a0666d53b9de69d390621298798c03b5190497 Reviewed-on: https://chromium-review.googlesource.com/934341Reviewed-by:
Michael Starzinger <mstarzinger@chromium.org> Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Cr-Commit-Position: refs/heads/master@{#51613}
-
Clemens Hammacher authored
The type std::enable_if<cond> does always exist, it only makes sense to check for std::enable_if<cond>::type. But the way this is used here we also cannot do that, so just replace this by a good old "#ifdef DEBUG". Drive-by: Minor unrelated cleanup (constexpr and ifdef). R=eholk@chromium.org Change-Id: I6bc27ee3adfd3ec3d38d61df67dd9cdff0faf2f7 Reviewed-on: https://chromium-review.googlesource.com/939387Reviewed-by:
Eric Holk <eholk@chromium.org> Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Cr-Commit-Position: refs/heads/master@{#51612}
-
Sigurd Schneider authored
Bug: v8:7310 Change-Id: Ia9e830ef9283b6890f505f15550170d1fd1f47b2 Reviewed-on: https://chromium-review.googlesource.com/939623Reviewed-by:
-
Sigurd Schneider authored
This change ensures that GVN does not move StringSubstring out of switches, which might introduce partial redundancies. Bug: chromium:816522 Change-Id: I63b91edd995c84b68d756ed5de08fa13567f3d80 Reviewed-on: https://chromium-review.googlesource.com/939621Reviewed-by:
-
sreten.kovacevic authored
Implement Spill and Fill instructions on MIPS in Liftoff along with some instructions that are needed for their implementation and that are using them directly. Also, fix issue with i32_set_cond that reproduced while implementing these instructions. Bug: v8:6600 Change-Id: I846f427e5d1345e9162ad3b2ffefe2a827732da1 Reviewed-on: https://chromium-review.googlesource.com/939399Reviewed-by:
-
Junliang Yan authored
Port c462ddc8 Original Commit Message: This makes sure that {JSFunction} invocations always load the code start address into the fixed {kJavaScriptCallCodeStartRegister} register. This allows us to perform PC-relative operations more effective. For now this only applies to code with {kCallJSFunction} linkage. R=mstarzinger@chromium.org, joransiu@ca.ibm.com, michael_dawson@ca.ibm.com BUG= LOG=N Change-Id: If346a3cbaea820b1fcec38c5105605496961a888 Reviewed-on: https://chromium-review.googlesource.com/938721Reviewed-by:
-
Ross McIlroy authored
Previously GetSharedFunctionInfoForStreamedScript didn't either check the compilation cache or put the result of compilation into the compilation cache. This would mean future compiles would need to re-parse / compile the same script even if the isolate had already seen it. This CL fixes this. Also refactors the compilation pipelines to ensure we call debug->OnAfterCompile() for all script compiles even when loading from a cache. BUG=v8:5203 Change-Id: I4b06bdfc566425f4e6d70fc3e6e080b0dc497d48 Reviewed-on: https://chromium-review.googlesource.com/939464 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by:
Mythri Alle <mythria@chromium.org> Cr-Commit-Position: refs/heads/master@{#51607}
-
Hannes Payer authored
Bug: chromium:774108 Change-Id: I5345fed261862b0e20356ec4579b16cdf0ea58a6 Reviewed-on: https://chromium-review.googlesource.com/899148 Commit-Queue: Hannes Payer <hpayer@chromium.org> Reviewed-by:
Michael Lippautz <mlippautz@chromium.org> Cr-Commit-Position: refs/heads/master@{#51606}
-
Michael Starzinger authored
R=cbruni@chromium.org BUG=v8:7438 Change-Id: I2359ff08f0c37c683bbcb164eb3120539d2bb124 Reviewed-on: https://chromium-review.googlesource.com/939468Reviewed-by:
Camillo Bruni <cbruni@chromium.org> Commit-Queue: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#51605}
-
Clemens Hammacher authored
When generating a 64bit memory operation on ia32, we need to emit two operations, one at {offset+4}, one at {offset}. The computation {offset+4} can overflow, which is ok because 1) it won't be used for code generation later, and 2) the generated code will not be reached because the memory access is always out of bounds anyway. R=ahaas@chromium.org Bug: v8:7499, v8:6600 Change-Id: Ia4660688c3291700c48efc201d15fc370b4dd854 Reviewed-on: https://chromium-review.googlesource.com/939389Reviewed-by: -
Camillo Bruni authored
The number of arguments passed on the stack might exceed the regular object size limits. Hence we need to emit write barriers when copying the arguments from the stack into the allocated array. Bug: chromium:813450 Change-Id: I829c5c32b1a7b5f4ddb01cc6ea92f85ab47126aa Reviewed-on: https://chromium-review.googlesource.com/939174Reviewed-by:
Igor Sheludko <ishell@chromium.org> Commit-Queue: Camillo Bruni <cbruni@chromium.org> Cr-Commit-Position: refs/heads/master@{#51603}
-
Mike Stanton authored
This is a reland of 800daded. Original change's description: > [turbofan] Masking/poisoning in codegen (optimized code, arm64) > > This introduces masking of loads with speculation bit during code generation. > At the moment, this is done only under the > --branch-load-poisoning flag, and this CL enlarges the set of supported > platforms from {x64, arm} to {x64, arm, arm64}. > > Overview of changes: > - new register configuration configuration with one register reserved for > the speculation poison/mask (kSpeculationPoisonRegister). > - in codegen, we introduce an update to the poison register at the starts > of all successors of branches (and deopts) that are marked as safety > branches (deopts). > - in memory optimizer, we lower all field and element loads to PoisonedLoads. > - poisoned loads are then masked in codegen with the poison register. > * only integer loads are masked at the moment. > > Bug: chromium:798964 > Change-Id: Ie6bc9c3bdac9998b0ef81f050a9c844399ca3ae4 > Reviewed-on: https://chromium-review.googlesource.com/928724 > Commit-Queue: Michael Stanton <mvstanton@chromium.org> > Reviewed-by: Martyn Capewell <martyn.capewell@arm.com> > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> > Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> > Cr-Commit-Position: refs/heads/master@{#51576} Bug: chromium:798964 Change-Id: I6c87d34c4e05fca0bd7f5447555133ecb0fb7a2e Reviewed-on: https://chromium-review.googlesource.com/939402Reviewed-by:
Martyn Capewell <martyn.capewell@arm.com> Reviewed-by:
Jaroslav Sevcik <jarin@chromium.org> Commit-Queue: Michael Stanton <mvstanton@chromium.org> Cr-Commit-Position: refs/heads/master@{#51602}
-
Clemens Hammacher authored
This adds support for f32.neg and f64.neg. Note that this cannot be computed as "0 - src", as this would not turn 0 into -0. Instead, we need to explicitly flip the sign bit. R=ahaas@chromium.org Bug: v8:6600 Change-Id: I3cbcfa156c5d2a727e0e2da279369bf055f0d657 Reviewed-on: https://chromium-review.googlesource.com/937202Reviewed-by:
-
Tobias Tebbi authored
Bug: chromium:814084 Change-Id: Ic23091e1cd778b09406c2bcde1a718e464655729 Reviewed-on: https://chromium-review.googlesource.com/939386Reviewed-by:
-
Peter Marshall authored
This will fire if the CAST is never useful. This is helpful if you add a TNode return type to a function - its callers no longer need to cast the result if the types are the same. Change-Id: If0b04c615cb2dbfa91ba43d5d0d35ace5a31d4e7 Reviewed-on: https://chromium-review.googlesource.com/934449Reviewed-by:
Tobias Tebbi <tebbi@chromium.org> Commit-Queue: Peter Marshall <petermarshall@chromium.org> Cr-Commit-Position: refs/heads/master@{#51599}
-
Jaroslav Sevcik authored
Turbofan can only handle 64K control inputs for merges. Such large can only be created by functions with 64K jumps, so we limit the bytecode size to the minimum size of bytecode arrays with 64K jumps. Bug: chromium:815392, v8:7438 Change-Id: I674705e87e19ce451b40d5827c9fe3e6ec17293a Reviewed-on: https://chromium-review.googlesource.com/938421 Commit-Queue: Jaroslav Sevcik <jarin@chromium.org> Reviewed-by:
-
Clemens Hammacher authored
Several cleanups: - unify identical macro defintions - use existing macros instead of duplicating the code - add AVX versions for xorps and xorpd (to be used by Liftoff) R=mstarzinger@chromium.org Bug: v8:7310, v8:6600 Change-Id: Id37c58cf6187533ad9d4a0ca8bc5d49f9de66785 Reviewed-on: https://chromium-review.googlesource.com/937124Reviewed-by:
-
Clemens Hammacher authored
This reverts commit 25427203. Reason for revert: code-coverage failures on gc-stress bot: https://build.chromium.org/p/client.v8/builders/V8%20Linux64%20GC%20Stress%20-%20custom%20snapshot/builds/17956 Original change's description: > Reland: [Compiler] Use CompilationCache for StreamedScript compilation. > > Previously GetSharedFunctionInfoForStreamedScript didn't either check the > compilation cache or put the result of compilation into the compilation > cache. This would mean future compiles would need to re-parse / compile > the same script even if the isolate had already seen it. This CL > fixes this. > > Also refactors the compilation pipelines to ensure we call debug->OnAfterCompile() > for all script compiles even when loading from a cache. > > BUG=v8:5203 > Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng > > Change-Id: I0a74c5b67bfaca5e50511d5f72da0ab53d8457f6 > Reviewed-on: https://chromium-review.googlesource.com/937724 > Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> > Reviewed-by: Mythri Alle <mythria@chromium.org> > Cr-Commit-Position: refs/heads/master@{#51594} TBR=rmcilroy@chromium.org,yangguo@chromium.org,mythria@chromium.org Change-Id: I784b9eeff75a677b9f2276fa05a0d1af09772baa No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: v8:5203 Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng Reviewed-on: https://chromium-review.googlesource.com/939401Reviewed-by:
-
Clemens Hammacher authored
There is a clear mistake of using kWasmF64 instead of kWasmF32. R=ahaas@chromium.org Change-Id: I638d568b3736fdb8417f17bcd04d17268a45b965 Reviewed-on: https://chromium-review.googlesource.com/939178Reviewed-by:
-
