- 21 Mar, 2017 1 commit
-
-
bbudge authored
- Adds a FinishCode method to CodeGenerator, and implements it for all platforms. ARM and ARM64 flush constants, all other platforms do nothing. - Remove old static free function. LOG=N BUG=none Review-Url: https://codereview.chromium.org/2748383004 Cr-Commit-Position: refs/heads/master@{#43990}
-
- 10 Feb, 2017 1 commit
-
-
verwaest authored
BUG= Review-Url: https://codereview.chromium.org/2682143002 Cr-Original-Commit-Position: refs/heads/master@{#43065} Committed: https://chromium.googlesource.com/v8/v8/+/193a0c118845d068ab386b5c90d04daaa64e1e86 Review-Url: https://codereview.chromium.org/2682143002 Cr-Commit-Position: refs/heads/master@{#43085}
-
- 09 Feb, 2017 2 commits
-
-
machenbach authored
Revert of [compiler] Pass deoptimization_kind through DeoptimizeParameters and FlagsContinuation (patchset #3 id:40001 of https://codereview.chromium.org/2682143002/ ) Reason for revert: cfi failure: https://build.chromium.org/p/client.v8/builders/V8%20Linux64%20-%20cfi/builds/8635 Original issue's description: > [compiler] Pass deoptimization_kind through DeoptimizeParameters and FlagsContinuation > > BUG= > > Review-Url: https://codereview.chromium.org/2682143002 > Cr-Commit-Position: refs/heads/master@{#43065} > Committed: https://chromium.googlesource.com/v8/v8/+/193a0c118845d068ab386b5c90d04daaa64e1e86 TBR=jarin@chromium.org,verwaest@chromium.org # Skipping CQ checks because original CL landed less than 1 days ago. NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true BUG= Review-Url: https://codereview.chromium.org/2683203002 Cr-Commit-Position: refs/heads/master@{#43070}
-
verwaest authored
BUG= Review-Url: https://codereview.chromium.org/2682143002 Cr-Commit-Position: refs/heads/master@{#43065}
-
- 31 Jan, 2017 1 commit
-
-
eholk authored
Previously this information was encoded in a FixedArray dangling off the Code object. This extra field seems to be responsible for increased memory usage, as seen in the linked bugs. In this change, we instead encode this in the RelocInfo and remove the field from the Code object. BUG= https://bugs.chromium.org/p/chromium/issues/detail?id=678583 BUG= https://bugs.chromium.org/p/chromium/issues/detail?id=671180 BUG= https://bugs.chromium.org/p/chromium/issues/detail?id=670733 Review-Url: https://codereview.chromium.org/2651833003 Cr-Commit-Position: refs/heads/master@{#42802}
-
- 22 Dec, 2016 1 commit
-
-
danno authored
* Ensure that a source position is already specified in generated code before prologue is assembled. * Ensure source position is set for instructions before their gaps are assembled (this fixes missing source position information at the beginning of deferred code). * Don't output source position information for gap moves that are redundant. This led to extraneous, confusing source positions for constants that did not end up producing any code. * Output source position information that is usable in turbolizer when --trace-turbo is specified. LOG=N Review-Url: https://codereview.chromium.org/2599433002 Cr-Commit-Position: refs/heads/master@{#41914}
-
- 15 Dec, 2016 1 commit
-
-
ahaas authored
Some instructions in WebAssembly trap for some inputs, which means that the execution is terminated and (at least at the moment) a JavaScript exception is thrown. Examples for traps are out-of-bounds memory accesses, or integer divisions by zero. Without the TrapIf and TrapUnless operators trap check in WebAssembly introduces 5 TurboFan nodes (branch, if_true, if_false, trap-reason constant, trap-position constant), in addition to the trap condition itself. Additionally, each WebAssembly function has four TurboFan nodes (merge, effect_phi, 2 phis) whose number of inputs is linear to the number of trap checks in the function. Especially for functions with high numbers of trap checks we observe a significant slowdown in compilation time, down to 0.22 MiB/s in the sqlite benchmark instead of the average of 3 MiB/s in other benchmarks. By introducing a TrapIf common operator only a single node is necessary per trap check, in addition to the trap condition. Also the nodes which are shared between trap checks (merge, effect_phi, 2 phis) would disappear. First measurements suggest a speedup of 30-50% on average. This CL only implements TrapIf and TrapUnless on x64. The implementation is also hidden behind the --wasm-trap-if flag. Please take a special look at how the source position is transfered from the instruction selector to the code generator, and at the context that is used for the runtime call. R=titzer@chromium.org Review-Url: https://codereview.chromium.org/2562393002 Cr-Commit-Position: refs/heads/master@{#41720}
-
- 05 Dec, 2016 1 commit
-
-
jarin authored
Review-Url: https://codereview.chromium.org/2546113002 Cr-Commit-Position: refs/heads/master@{#41469}
-
- 30 Nov, 2016 1 commit
-
-
eholk authored
During codegen, we build a list mapping protected instructions to their associated landing pads. This will ultimately by used by the signal handler to recover from out of bounds faults and throw a JS exception. This is mostly pulled from my larger in-progress CL at https://codereview.chromium.org/2371833007/. BUG= https://bugs.chromium.org/p/v8/issues/detail?id=5277 Review-Url: https://codereview.chromium.org/2500443004 Cr-Commit-Position: refs/heads/master@{#41400}
-
- 02 Nov, 2016 2 commits
-
-
danno authored
This is preparation for using TF to create builtins that handle variable number of arguments and have to remove these arguments dynamically from the stack upon return. The gist of the changes: - Added a second argument to the Return node which specifies the number of stack slots to pop upon return in addition to those specified by the Linkage of the compiled function. - Removed Tail -> Non-Tail fallback in the instruction selector. Since TF now should handles all tail-call cases except where the return value type differs, this fallback was not really useful and in fact caused unexpected behavior with variable sized argument popping, since it wasn't possible to materialize a Return node with the right pop count from the TailCall without additional context. - Modified existing Return generation to pass a constant zero as the additional pop argument since the variable pop functionality LOG=N Review-Url: https://codereview.chromium.org/2446543002 Cr-Commit-Position: refs/heads/master@{#40699}
-
machenbach authored
Revert of [turbofan] Support variable size argument popping in TF-generated functions (patchset #13 id:240001 of https://codereview.chromium.org/2446543002/ ) Reason for revert: Seems to break arm64 sim debug and blocks roll: https://build.chromium.org/p/client.v8.ports/builders/V8%20Linux%20-%20arm64%20-%20sim%20-%20debug/builds/3294 Original issue's description: > [turbofan] Support variable size argument removal in TF-generated functions > > This is preparation for using TF to create builtins that handle variable number of > arguments and have to remove these arguments dynamically from the stack upon > return. > > The gist of the changes: > - Added a second argument to the Return node which specifies the number of stack > slots to pop upon return in addition to those specified by the Linkage of the > compiled function. > - Removed Tail -> Non-Tail fallback in the instruction selector. Since TF now should > handles all tail-call cases except where the return value type differs, this fallback > was not really useful and in fact caused unexpected behavior with variable > sized argument popping, since it wasn't possible to materialize a Return node > with the right pop count from the TailCall without additional context. > - Modified existing Return generation to pass a constant zero as the additional > pop argument since the variable pop functionality > > LOG=N TBR=bmeurer@chromium.org,mstarzinger@chromium.org,epertoso@chromium.org,danno@chromium.org # Not skipping CQ checks because original CL landed more than 1 days ago. NOPRESUBMIT=true Review-Url: https://codereview.chromium.org/2473643002 Cr-Commit-Position: refs/heads/master@{#40691}
-
- 31 Oct, 2016 1 commit
-
-
danno authored
This is preparation for using TF to create builtins that handle variable number of arguments and have to remove these arguments dynamically from the stack upon return. The gist of the changes: - Added a second argument to the Return node which specifies the number of stack slots to pop upon return in addition to those specified by the Linkage of the compiled function. - Removed Tail -> Non-Tail fallback in the instruction selector. Since TF now should handles all tail-call cases except where the return value type differs, this fallback was not really useful and in fact caused unexpected behavior with variable sized argument popping, since it wasn't possible to materialize a Return node with the right pop count from the TailCall without additional context. - Modified existing Return generation to pass a constant zero as the additional pop argument since the variable pop functionality LOG=N Review-Url: https://codereview.chromium.org/2446543002 Cr-Commit-Position: refs/heads/master@{#40678}
-
- 26 Sep, 2016 1 commit
-
-
tebbi authored
R=bmeurer@chromium.org,jarin@chromium.org BUG= Review-Url: https://codereview.chromium.org/2366993002 Cr-Commit-Position: refs/heads/master@{#39733}
-
- 21 Sep, 2016 1 commit
-
-
mstarzinger authored
This removes an optimization from the code generator that tries to materialize certain constants (i.e. context and closure) from the stackframe when possible. This does not work with Harmony tail calls which are split into several instructions. There have already been numerous bugs in this optimization, it is too fragile in its current form. R=bmeurer@chromium.org TEST=mjsunit/regress/regress-crbug-648539 BUG=chromium:648539 Review-Url: https://codereview.chromium.org/2357583003 Cr-Commit-Position: refs/heads/master@{#39583}
-
- 31 Aug, 2016 1 commit
-
-
marja authored
This way, many files which only need CompilationInfo but not compiler.h and its dependencies can include just compilation-info.h. BUG= Review-Url: https://codereview.chromium.org/2284313003 Cr-Commit-Position: refs/heads/master@{#39038}
-
- 23 Aug, 2016 1 commit
-
-
marja authored
Rebuilding (after touching certain files) is crazy slow because includes are out of control. Fixing it: - Don't include stuff in headers unless necessary. - Include the stuff you need, not some other stuff that happens to include the stuff you need. BUG=v8:5294 Review-Url: https://codereview.chromium.org/2268303002 Cr-Commit-Position: refs/heads/master@{#38818}
-
- 12 Aug, 2016 2 commits
-
-
ahaas authored
Revert of [turbofan] Split CodeGenerator::GenerateCode into AssembleCode and FinishCodeObject. (patchset #3 id:40001 of https://codereview.chromium.org/2229243003/ ) Reason for revert: There is a data race in the initialization of the Isolate::random_number_generator() Original issue's description: > [turbofan] Split CodeGenerator::GenerateCode into AssembleCode and FinishCodeObject. > > This CL splits CodeGenerator::GenerateCode into two new functions: > AssembleCode and FinishCodeObject. AssembleCode does not access or > modify the JS heap, which means that AssembleCode can be executed on > background threads. FinishCodeObject allocates the generated code object > on the JS heap and therefore has to be executed on the main thread. > > Implementation details: > The GenerateCode function has been split just before out-of-line code is > assembled. The reason is that code stubs may be generated when > out-of-line code is assembled, which potentially allocates these code > stubs on the heap. > > - Parts of initialization of the CodeGenerator has been moved from the > constructor to an Initialize function so that we can instantiate an empty > CodeGenerator object in PipelineData. > > R=bmeurer@chromium.org, mstarzinger@chromium.org, titzer@chromium.org > > Committed: https://crrev.com/03058a2187e32cc4080612181802086527c116a2 > Cr-Commit-Position: refs/heads/master@{#38604} TBR=bmeurer@chromium.org,mstarzinger@chromium.org,titzer@chromium.org # Skipping CQ checks because original CL landed less than 1 days ago. NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true Review-Url: https://codereview.chromium.org/2240523003 Cr-Commit-Position: refs/heads/master@{#38605}
-
ahaas authored
This CL splits CodeGenerator::GenerateCode into two new functions: AssembleCode and FinishCodeObject. AssembleCode does not access or modify the JS heap, which means that AssembleCode can be executed on background threads. FinishCodeObject allocates the generated code object on the JS heap and therefore has to be executed on the main thread. Implementation details: The GenerateCode function has been split just before out-of-line code is assembled. The reason is that code stubs may be generated when out-of-line code is assembled, which potentially allocates these code stubs on the heap. - Parts of initialization of the CodeGenerator has been moved from the constructor to an Initialize function so that we can instantiate an empty CodeGenerator object in PipelineData. R=bmeurer@chromium.org, mstarzinger@chromium.org, titzer@chromium.org Review-Url: https://codereview.chromium.org/2229243003 Cr-Commit-Position: refs/heads/master@{#38604}
-
- 02 Aug, 2016 1 commit
-
-
mstarzinger authored
This completely removes translation of exception handler predictions from the graph IR. We now rely on the runtime using deoptimization infomation via {FrameSummary} for predictions in optimized code. R=bmeurer@chromium.org Review-Url: https://codereview.chromium.org/2207533002 Cr-Commit-Position: refs/heads/master@{#38250}
-
- 22 Jul, 2016 1 commit
-
-
yangguo authored
This is in preparation to implementing exception prediction for async functions. Each handler table entry can now predict "caught", "uncaught", or "promise". The latter indicates that the exception will lead to a promise rejection. To mark the relevant try-catch blocks, we add a new native syntax. try { } %catch (e) { } indicates a TryCatchStatement with the "promise" prediction. The previous implementation of using the function to tell the relevant try-catch apart from inner try-catch blocks will not work for async functions since these can have inner try-catch blocks inside the same function. BUG=v8:5167 Review-Url: https://codereview.chromium.org/2161263003 Cr-Commit-Position: refs/heads/master@{#37966}
-
- 18 Jul, 2016 1 commit
-
-
bmeurer authored
So far TurboFan wasn't adding the deoptimization reasons for eager/soft deoptimization exits that can be used by either the DevTools profiler or the --trace-deopt flag. This adds basic support for deopt reasons on Deoptimize, DeoptimizeIf and DeoptimizeUnless nodes and threads through the reasons to the code generation. Also moves the DeoptReason to it's own file (to resolve include cycles) and drops unused reasons. R=jarin@chromium.org Review-Url: https://codereview.chromium.org/2161543002 Cr-Commit-Position: refs/heads/master@{#37823}
-
- 15 Jul, 2016 1 commit
-
-
ssanfilippo authored
This commit introduces support for writing unwinding tables in the .eh_frame format, to be inserted in the jitdump read by Linux perf and emitted with FLAG_perf_prof and FLAG_perf_prof_unwinding_info enabled. x64 is fully implemented and tested, arm and arm64 are untested and the unwinding information needs to be expanded, but the mechanism is ready. BUG=v8:4899 LOG=N Review-Url: https://codereview.chromium.org/2026313002 Cr-Commit-Position: refs/heads/master@{#37799}
-
- 01 Jul, 2016 1 commit
-
-
danno authored
This optimizes the passing of stack parameters in function calls. For some architectures (ia32/x64), using pushes when possible instead of bumping the stack and then storing parameters generates much smaller code, and in some cases is faster (e.g. when a push of a memory location can implement a memory-to-memory copy and thus elide an intermediate load. On others (e.g. ARM), the benefit is smaller, where it's only possible to elide direct stack pointer adjustment in certain cases or combine multiple register stores into a single instruction in other limited situations. On yet other platforms (ARM64, MIPS), there are no push instructions, and this optimization isn't used at all. Ideally, this mechanism would be used for both tail calls and normal calls, but "normal" calls are currently pretty efficient, and tail calls are very inefficient, so this CL sets the bar low for building a new mechanism to handle parameter pushing that only needs to raise the bar on tail calls for now. The key aspect of this change is that adjustment to the stack pointer for tail calls (and perhaps later real calls) is an explicit step separate from instruction selection and gap resolution, but aware of both, making it possible to safely recognize gap moves that are actually pushes. Review-Url: https://codereview.chromium.org/2082263002 Cr-Commit-Position: refs/heads/master@{#37477}
-
- 29 Jun, 2016 1 commit
-
-
yangguo authored
R=bmeurer@chromium.org BUG=v8:5117 Review-Url: https://codereview.chromium.org/2109673003 Cr-Commit-Position: refs/heads/master@{#37392}
-
- 03 May, 2016 1 commit
-
-
bmeurer authored
Use the ShiftLeftStub, ShiftRightStub and ShiftRightLogicalStub in JSGenericLowering instead of the old-style patching BinaryOpIC. Also remove the machinery to support patching ICs in TurboFan completely, as this was the last user of code patching in TurboFan! R=yangguo@chromium.org Review-Url: https://codereview.chromium.org/1942153002 Cr-Commit-Position: refs/heads/master@{#35959}
-
- 28 Apr, 2016 1 commit
-
-
jarin authored
BUG=chromium:607115 LOG=n Review-Url: https://codereview.chromium.org/1928903002 Cr-Commit-Position: refs/heads/master@{#35855}
-
- 20 Apr, 2016 1 commit
-
-
mtrofin authored
Before frame elision, we finalized the frame shape when assembling the prologue, which is also when we prepared the frame (saving sp, etc). The frame finalization only needs to happen once, and happens to be actually a set of idempotent operations. With frame elision, the logic for frame finalization was happening every time we constructed the frame. Albeit idempotent operations, the code would become hard to maintain. This change separates frame shape finalization from frame construction. When constructing the CodeGenerator, we finalize the frame. Subsequent access is to a const Frame*. Also renamed AssemblePrologue to AssembleConstructFrame, as suggested in the frame elision CR. Separating frame setup gave the opportunity to do away with architecture-independent frame aligning (which is something just arm64 cares about), and also with stack pointer setup (also arm64). Both of these happen now at frame finalization on arm64. BUG= Review URL: https://codereview.chromium.org/1843143002 Cr-Commit-Position: refs/heads/master@{#35642}
-
- 31 Mar, 2016 1 commit
-
-
mbrandy authored
Port 53d51c52 Includes fixes required for embedded constant pools. Original commit message: Removed Frame::needs_frame and the function-wide logic using it in favor of FrameAccessState::has_frame, which can be set on a more granular level, and driving it block by block. R=mtrofin@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com, rmcilroy@chromium.org BUG=v8:4533 LOG=N Review URL: https://codereview.chromium.org/1843273002 Cr-Commit-Position: refs/heads/master@{#35166}
-
- 30 Mar, 2016 1 commit
-
-
mtrofin authored
Removed Frame::needs_frame and the function-wide logic using it in favor of FrameAccessState::has_frame, which can be set on a more granular level, and driving it block by block. BUG= v8:4533 LOG=N Review URL: https://codereview.chromium.org/1775323002 Cr-Commit-Position: refs/heads/master@{#35139}
-
- 13 Mar, 2016 1 commit
-
-
jarin authored
BUG=chromium:582702 LOG=N Review URL: https://codereview.chromium.org/1781393002 Cr-Commit-Position: refs/heads/master@{#34736}
-
- 08 Mar, 2016 1 commit
-
-
ishell authored
In case when F tail calls G we should also remove the potential arguments adaptor frame for F. This CL introduces two new machine instructions ArchTailCallCodeObjectFromJSFunction and ArchTailCallJSFunctionFromJSFunction which (unlike existing ArchTailCallCodeObject and ArchTailCallJSFunction) also drop arguments adaptor frame if it exists right before jumping to the target function. BUG=v8:4698 LOG=N Review URL: https://codereview.chromium.org/1702423002 Cr-Commit-Position: refs/heads/master@{#34566}
-
- 24 Feb, 2016 1 commit
-
-
bmeurer authored
These macro operators represent a conditional eager deoptimization exit without explicit branching, which greatly reduces overhead of both scheduling and register allocation, and thereby greatly reduces overall compilation time, esp. when there are a lot of eager deoptimization exits. R=jarin@chromium.org Review URL: https://codereview.chromium.org/1721103003 Cr-Commit-Position: refs/heads/master@{#34239}
-
- 05 Jan, 2016 2 commits
-
-
thestig authored
Review URL: https://codereview.chromium.org/1542143003 Cr-Commit-Position: refs/heads/master@{#33122}
-
sigurds authored
Deopt support is added on two levels. On the IR level, a new ObjectState node is added, which represenents an object to be materialized. ObjectState nodes appear as inputs of FrameState and StateValues nodes. On the instruction select/code-generation level, the FrameStateDescriptor class handles the nesting introduced by ObjectState, and ensures that deopt code with CAPTURED_OBJECT/DUPLICATED_OBJECT entries are generated similarly to what crankshaft's escape analysis does. Two unittests test correctness of the IR level implementation. Correctness for instruction selection / code generation is tested by mjsunit tests. R=jarin@chromium.org,mstarzinger@chromium.org BUG=v8:4586 LOG=n Review URL: https://codereview.chromium.org/1485183002 Cr-Commit-Position: refs/heads/master@{#33115}
-
- 24 Nov, 2015 1 commit
-
-
danno authored
Some highlights of this CL: * Refactor the mutable state out of Frame into FrameAccessState, which is maintained and updated during code generation to record whether sp- or fp-based frame access is currently active and how deep the stack on top of the frame is. * The operand resultion in linkage.cc now uses FrameAccessState to determine how to generate frame-accessing operands. * Update all platforms to accurately track additionally pushed stack slots (e.g. arguments for calls) in the FrameAccessState. * Add a flag, --turbo_sp_frame_access, which forces all frame access to be sp-based whenever possible. This will likely never be used in production, but for testing it's useful in verifying that the stack-tracking of each platform maintained in the FrameAccessState is correct. * Use sp-based frame access for gap resolving before tail calls. This will allow for slightly more efficient restoration of the frame pointer in the tail call in a later CL. * Remove most ad hoc groping into CallDescriptors to determine if a frame is needed, instead consistently use predicates like needs_frame(), IsCFunctionCall() and IsJSFunctionCall(). BUG=v8:4076 LOG=n Review URL: https://codereview.chromium.org/1460183002 Cr-Commit-Position: refs/heads/master@{#32234}
-
- 20 Nov, 2015 1 commit
-
-
danno authored
* Adds a PrepareForTailCall instruction that bumps the stack in the case that the number of parameters passed to the callee causes the stack to exceed the calleer's frame size. * Uses the gap resolver to move the saved caller return address and frame pointer to the approprate location in the tail-called frame. BUG=v8:4076 LOG=n Review URL: https://codereview.chromium.org/1455833004 Cr-Commit-Position: refs/heads/master@{#32151}
-
- 13 Nov, 2015 1 commit
-
-
danno authored
* Limit triggering of tail calls to explicit use of a new inline runtime function %_TailCall. %_TailCall works just like %_Call except for using tail-calling mechanics (currently only in TF). * Remove hack that recognized some specific usages of %_Call and converted them into tail calls. * Support tail calls for all calls where the number of callee stack parameters is less than or equal to the number of caller stack parameters. * Use the gap resolver to swizzle parameters and registers to tail calls. BUG=v8:4076 LOG=n Review URL: https://codereview.chromium.org/1439613003 Cr-Commit-Position: refs/heads/master@{#31987}
-
- 26 Jun, 2015 1 commit
-
-
bmeurer authored
This optimization is already implemented in fullcodegen, and basically makes sure that we do not unecessarily blow up the code with duplicated return sequences everywhere. R=danno@chromium.org Review URL: https://codereview.chromium.org/1211373002 Cr-Commit-Position: refs/heads/master@{#29315}
-
- 28 May, 2015 2 commits
-
-
mstarzinger authored
This introduces a conservative prediction for each exception handler whether it will locally catch an exception or re-throw it to outside the code bondaries. It will allow for a more intuitive prediction of whether an exception is considered "caught" or "uncaught". R=bmeurer@chromium.org,yangguo@chromium.org BUG=chromium:492522 LOG=N Review URL: https://codereview.chromium.org/1158563008 Cr-Commit-Position: refs/heads/master@{#28681}
-
bmeurer authored
We need the shared function info of inlined functions to prevent code flushing for their unoptimized code, and also to make sure that liveedit can find the proper functions to deoptimize. R=jarin@chromium.org Review URL: https://codereview.chromium.org/1156403002 Cr-Commit-Position: refs/heads/master@{#28677}
-