- 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}
-
- 12 Apr, 2016 1 commit
-
-
ahaas authored
The parameter is not used at the moment, so I removed it. R=bmeurer@chromium.org Review URL: https://codereview.chromium.org/1876833003 Cr-Commit-Position: refs/heads/master@{#35403}
-
- 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}
-
- 11 Mar, 2016 1 commit
-
-
danno authored
Review URL: https://codereview.chromium.org/1777013004 Cr-Commit-Position: refs/heads/master@{#34709}
-
- 08 Mar, 2016 1 commit
-
-
danno authored
Before this CL, various code stubs used different techniques for marking their frames to enable stack-crawling and other access to data in the frame. All of them were based on a abuse of the "standard" frame representation, e.g. storing the a context pointer immediately below the frame's fp, and a function pointer after that. Although functional, this approach tends to make stubs and builtins do an awkward, unnecessary dance to appear like standard frames, even if they have nothing to do with JavaScript execution. This CL attempts to improve this by: * Ensuring that there are only two fundamentally different types of frames, a "standard" frame and a "typed" frame. Standard frames, as before, contain both a context and function pointer. Typed frames contain only a minimum of a smi marker in the position immediately below the fp where the context is in standard frames. * Only interpreted, full codegen, and optimized Crankshaft and TurboFan JavaScript frames use the "standard" format. All other frames use the type frame format with an explicit marker. * Typed frames can contain one or more values below the type marker. There is new magic macro machinery in frames.h that simplifies defining the offsets of these fields in typed frames. * A new flag in the CallDescriptor enables specifying whether a frame is a standard frame or a typed frame. Secondary register location spilling is now only enabled for standard frames. * A zillion places in the code have been updated to deal with the fact that most code stubs and internal frames use the typed frame format. This includes changes in the deoptimizer, debugger, and liveedit. * StandardFrameConstants::kMarkerOffset is deprecated, (CommonFrameConstants::kContextOrFrameTypeOffset and StandardFrameConstants::kFrameOffset are now used in its stead). LOG=N Review URL: https://codereview.chromium.org/1696043002 Cr-Commit-Position: refs/heads/master@{#34571}
-
- 11 Jan, 2016 1 commit
-
-
titzer authored
R=bmeurer@chromium.org BUG= Review URL: https://codereview.chromium.org/1578723002 Cr-Commit-Position: refs/heads/master@{#33202}
-
- 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}
-
- 19 Nov, 2015 1 commit
-
-
jacob.bramley authored
A64 loads and stores can have much larger positive than negative immediate offsets, and since most frame slots are below fp, we can significantly improve accesses by basing them on sp instead. Typical example: Before After mov x16, #-416 str x20, [fp, x16] str x20, [jssp, #32] Notable benchmark results include lua_binarytrees, which improves by about 7.5% on A57 and 5% on A53. Several other asm.js benchmarks gain 2-4%. Review URL: https://codereview.chromium.org/1376173003 Cr-Commit-Position: refs/heads/master@{#32111}
-
- 18 Aug, 2015 1 commit
-
-
danno authored
Previously, it was not possible to specify StackSlotOperands for all slots in both the caller and callee stacks. Specifically, the region of the callee's stack including the saved return address, frame pointer, function pointer and context pointer could not be addressed by the register allocator/gap resolver. In preparation for better tail call support, which will use the gap resolver to reconcile outgoing parameters, this change makes it possible to address all slots on the stack, because slots in the previously inaccessible dead zone may become parameter slots for outgoing tail calls. All caller stack slots are accessible as they were before, with slot -1 corresponding to the last stack parameter. Stack slot indices >= 0 access the callee stack, with slot 0 corresponding to the callee's saved return address, 1 corresponding to the saved frame pointer, 2 corresponding to the current function context, 3 corresponding to the frame marker/JSFunction, and slots 4 and above corresponding to spill slots. The following changes were specifically needed: * Frame has been changed to explicitly manage three areas of the callee frame, the fixed header, the spill slot area, and the callee-saved register area. * Conversions from stack slot indices to fp offsets all now go through a common bottleneck: OptimizedFrame::StackSlotOffsetRelativeToFp * The generation of deoptimization translation tables has been changed to support the new stack slot indexing scheme. Crankshaft, which doesn't support the new slot numbering in its register allocator, must adapt the indexes when creating translation tables. * Callee-saved parameters are now kept below spill slots, not above, to support saving only the optimal set of used registers, which is only known after register allocation is finished and spill slots have been allocated. Review URL: https://codereview.chromium.org/1261923007 Cr-Commit-Position: refs/heads/master@{#30224}
-