Skip to content

V
V8
Switch branch/tag
  1. 06 May, 2016 1 commit
  3. 05 May, 2016 1 commit
  5. 04 May, 2016 1 commit
  7. 03 May, 2016 2 commits
  9. 28 Apr, 2016 1 commit
  11. 24 Apr, 2016 1 commit
    • bmeurer's avatar
      [turbofan] Introduce TruncateTaggedToWord32 simplified operator. · 0231a7ef
      bmeurer authored 
      This allows us to get rid of the "push TruncateFloat64ToInt32 into Phi"
trick that was used in the MachineOperatorReducer to combine the
ChangeTaggedToFloat64 and TruncateFloat64ToInt32 operations. Instead of
doing that later, we can just introduce the proper operator during the
representation selection directly.

Also separate the TruncateFloat64ToInt32 machine operator, which had two
different meanings depending on a flag (either JavaScript truncation or
C++ style round to zero). Now there's a TruncateFloat64ToWord32 which
represents the JavaScript truncation (implemented via TruncateDoubleToI
macro + code stub) and the RoundFloat64ToInt32, which implements the C++
round towards zero operation (in the same style as the other WebAssembly
driven Round* machine operators).

R=jarin@chromium.org

Review URL: https://codereview.chromium.org/1919513002

Cr-Commit-Position: refs/heads/master@{#35743}
      0231a7ef
  13. 20 Apr, 2016 1 commit
    • mtrofin's avatar
      [turbofan] CodeGenerator: Frame setup refactoring · 81a1530e
      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}
      81a1530e
  15. 19 Apr, 2016 1 commit
  17. 18 Apr, 2016 1 commit
  19. 16 Apr, 2016 2 commits
  21. 14 Apr, 2016 1 commit
    • rmcilroy's avatar
      [Interpreter] Make dispatch table point to code entry instead of code objects. · 0c05e02f
      rmcilroy authored 
      Modifies Ignition to store code entry addresses in the dispatch table
rather than code objects. This allows the interpreter to avoid
calculating the code entry address from the code object on every
dispatch and provides a ~5-7% performance improvement on Octane with
Ignition.

This change adds ArchOpcode::kArchTailCallAddress to TurboFan to enable
tail call dispatch using these code addresses. It also adds a Dispatch
linkage creator (distinct from the stub linkage type used previously) to
allow targetting a code address target (which will diverge further from
the stub linkage type when we remove the context machine register in
Ignition).

BUG=v8:4280
LOG=N

Review URL: https://codereview.chromium.org/1882073002

Cr-Commit-Position: refs/heads/master@{#35480}
      0c05e02f
  23. 13 Apr, 2016 1 commit
  25. 06 Apr, 2016 1 commit
  27. 01 Apr, 2016 1 commit
  29. 31 Mar, 2016 1 commit
    • ahaas's avatar
      [wasm] Fixed float-to-int conversion tests. · ac7f0e2b
      ahaas authored 
      *) For all tests the input validation was incorrect, i.e. some values
were considered invalid although they were valid. The problem was that
values which are outside int range can get in range through truncation.

*) Removed an assertion in the x64 code generation of
TruncateFloat64ToUint32 which trapped on negative inputs.

*) Introduced a new TF operator TruncateFloat32ToUint32 which does
the same as ChangeFloat32ToUint32 but does not trap on negative inputs.

R=titzer@chromium.org

Review URL: https://codereview.chromium.org/1843983002

Cr-Commit-Position: refs/heads/master@{#35176}
      ac7f0e2b
  31. 30 Mar, 2016 1 commit
  33. 13 Mar, 2016 1 commit
  35. 09 Mar, 2016 1 commit
  37. 08 Mar, 2016 2 commits
    • danno's avatar
      [runtime] Unify and simplify how frames are marked · 9dcd0857
      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}
      9dcd0857
    • ishell's avatar
      [turbofan] Further fixing ES6 tail call elimination in Turbofan. · 2aae579c
      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}
      2aae579c
  39. 03 Mar, 2016 1 commit
  41. 29 Feb, 2016 1 commit
    • bmeurer's avatar
      [stubs] Introduce a proper ToBooleanStub. · d1df58e8
      bmeurer authored 
      Rename the existing (patching) ToBooleanStub to ToBooleanICStub to match
our naming convention, and add a new TurboFan-powered ToBooleanStub,
which just does the ToBoolean conversion without any runtime call or
code patching, so we can use it for Ignition (and TurboFan).

Drive-by-fix: Add an Oddball::to_boolean field similar to the ones we
already have for to_string and to_number, so we don't need to actually
dispatch on the concrete Oddball at all.

R=epertoso@chromium.org, rmcilroy@chromium.org, yangguo@chromium.org

Review URL: https://codereview.chromium.org/1744163002

Cr-Commit-Position: refs/heads/master@{#34361}
      d1df58e8
  43. 25 Feb, 2016 1 commit
  45. 24 Feb, 2016 1 commit
  47. 22 Feb, 2016 1 commit
  49. 19 Feb, 2016 1 commit
  51. 18 Feb, 2016 2 commits
  53. 17 Feb, 2016 2 commits
  55. 16 Feb, 2016 4 commits
  57. 15 Feb, 2016 1 commit
    • bmeurer's avatar
      [turbofan] Remove the function reload hack for OSR. · 359ba8e0
      bmeurer authored 
      Initially we were unable to address certain stack slots in the callee
part of the frame, including the function marker, therefore we had to
hack a reload of the function register into the OSR prologue. Now that
we are able to address all stack slots, we no longer need this hack.

R=jarin@chromium.org

Review URL: https://codereview.chromium.org/1666073002

Cr-Commit-Position: refs/heads/master@{#33974}
      359ba8e0
  59. 06 Feb, 2016 2 commits
  61. 03 Feb, 2016 1 commit