Skip to content

V
V8
Switch branch/tag
  1. 02 May, 2016 1 commit
    • bjaideep's avatar
      PPC: [turbofan] Run everything after representation selection concurrently. · 98b074cb
      bjaideep authored 
      Port d1b3d426

Original commit message:

    Further refactor the pipeline to even run the first scheduler (part of
    the effect control linearization) concurrently. This temporarily
    disables most of the write barrier elimination, but we will get back to
    that later.

    Drive-by-fix: Remove the dead code from ChangeLowering, and stack
    allocate the Typer in the pipeline. Also migrate the AllocateStub to a
    native code builtin, so that we have the code object + a handle to it
    available all the time.

R=bmeurer@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com, mbrandy@us.ibm.com

BUG=v8:4969
LOG=N

Review-Url: https://codereview.chromium.org/1941613002
Cr-Commit-Position: refs/heads/master@{#35938}
      98b074cb
  3. 27 Apr, 2016 1 commit
  5. 25 Apr, 2016 1 commit
    • mstarzinger's avatar
      [compiler] Add baseline tier to compilation pipeline. · 3fc0224c
      mstarzinger authored 
      This adds a baseline tier to the compilation pipeline. Currently this
tier is used to model a path from the interpreter to optimized code via
full-codegen code (to ensure sufficient type feedback). Switching from
the unoptimized tier to the baseline tier is limited to happen only when
there are no activations of the given function on the stack.

R=rmcilroy@chromium.org,bmeurer@chromium.org

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

Cr-Commit-Position: refs/heads/master@{#35757}
      3fc0224c
  7. 22 Apr, 2016 1 commit
    • bjaideep's avatar
      PPC: [interpreter] Heal closures when bytecode array is gone. · 6d9c4c86
      bjaideep authored 
      Port 5c8609de

Original commit message:

    This ensures the InterpreterEntryTrampoline heals code entry fields
    inside closures when being called without a valid bytecode array. This
    is preparatory work to allow removal of bytecode when switching some
    functions to other types of code.

R=mstarzinger@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com, mbrandy@us.ibm.com

BUG=v8:4280
LOG=N

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

Cr-Commit-Position: refs/heads/master@{#35739}
      6d9c4c86
  9. 19 Apr, 2016 1 commit
  11. 18 Apr, 2016 2 commits
  13. 15 Apr, 2016 1 commit
  15. 14 Apr, 2016 2 commits
    • mbrandy's avatar
      PPC: [Interpreter] Make dispatch table point to code entry instead of code objects. · 6c702283
      mbrandy authored 
      Port 0c05e02f

Original commit message:
    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).

R=rmcilroy@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com, bjaideep@ca.ibm.com
BUG=v8:4280
LOG=N

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

Cr-Commit-Position: refs/heads/master@{#35501}
      6c702283
    • mbrandy's avatar
      PPC: Visit the Optimized Code Map on first call rather than closure creation. · d7bb46d4
      mbrandy authored 
      Port 9336f4cc

Original commit message:
    This is useful for escape analysis, and helps upcoming changes to
    type feedback gathering.

R=mvstanton@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com, bjaideep@ca.ibm.com
BUG=

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

Cr-Commit-Position: refs/heads/master@{#35461}
      d7bb46d4
  17. 12 Apr, 2016 1 commit
  19. 06 Apr, 2016 1 commit
    • mbrandy's avatar
      PPC: [generators] Decouple generator resume from fullcodegen. · 1e001e71
      mbrandy authored 
      Port 974721c6

Original commit message:
    Introduce a ResumeGeneratorTrampoline, which does the actual stack state
    reconstruction (currently always restores a fullcodegen frame), and
    introduce appropriate TurboFan builtins for %GeneratorPrototype%.next,
    %GeneratorPrototype%.return and %GeneratorPrototype%.throw based on
    this native builtin.

    Also unify the flooding in case of step-in to always work based on
    JSFunction and remove the special casing for JSGeneratorObject.

R=bmeurer@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com, bjaideep@ca.ibm.com
BUG=chromium:513471
LOG=n

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

Cr-Commit-Position: refs/heads/master@{#35314}
      1e001e71
  21. 29 Mar, 2016 1 commit
  23. 22 Mar, 2016 2 commits
  25. 10 Mar, 2016 1 commit
  27. 09 Mar, 2016 1 commit
    • mbrandy's avatar
      PPC: [runtime] Unify and simplify how frames are marked · 4445c095
      mbrandy authored 
      Port 9dcd0857

Original commit message:
    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).

R=danno@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com
BUG=

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

Cr-Commit-Position: refs/heads/master@{#34643}
      4445c095
  29. 08 Mar, 2016 1 commit
  31. 07 Mar, 2016 1 commit
    • mbrandy's avatar
      PPC: [crankshaft] Support ES6 tail call elimination. · 826f67be
      mbrandy authored 
      Port 22938040

Original commit message:
    HInvokeFunction and HApplyArguments instructions now support tail calling.

    Inlining of calls at tail position is not supported yet and therefore still disabled.

    The tail-call-megatest was modified so that the usages of "arguments" object do not disable Crankshaft.

R=ishell@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com
BUG=v8:4698
LOG=N

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

Cr-Commit-Position: refs/heads/master@{#34563}
      826f67be
  33. 03 Mar, 2016 1 commit
  35. 22 Feb, 2016 1 commit
  37. 19 Feb, 2016 2 commits
    • mbrandy's avatar
      PPC: [stubs] Introduce a dedicated FastNewObjectStub. · a509b105
      mbrandy authored 
      Port ba2077aa

Original commit message:
    Move the already existing fast case for %NewObject into a dedicated
    FastNewObjectStub that we can utilize in places where we would otherwise
    fallback to %NewObject immediately, which is rather expensive.

    Also use FastNewObjectStub as the generic implementation of JSCreate,
    which should make constructor inlining based on SharedFunctionInfo (w/o
    specializing to a concrete closure) viable soon.

R=bmeurer@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com
BUG=

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

Cr-Commit-Position: refs/heads/master@{#34169}
      a509b105
    • rmcilroy's avatar
      [Interpreter] Enable runtime profiler support for Ignition. · b62bf1e6
      rmcilroy authored 
      Adds a profiling counter to each BytecodeArray object, and adds
code to Jump and Return bytecode handlers to update this
counter by the size of the jump or the distance from the return
to the start of the function. This is more accurate than fullcodegen's
approach since it takes forward jumps into account as well as back-edges.

Modifies RuntimeProfiler to track ticks for interpreted frames.
Currently we use the SharedFunctionInfo::profiler_ticks() instead
of adding another to tick field to avoid adding another field to
BytecodeArray since SharedFunctionInfo::profiler_ticks() is only
used by Crankshaft otherwise so we shouldn't need both for

BUG=v8:4689
LOG=N

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

Cr-Commit-Position: refs/heads/master@{#34166}
      b62bf1e6
  39. 18 Feb, 2016 2 commits
  41. 17 Feb, 2016 1 commit
  43. 16 Feb, 2016 1 commit
  45. 12 Feb, 2016 2 commits
    • mbrandy's avatar
      PPC: [runtime] Introduce FastNewStrictArgumentsStub to optimize strict arguments. · fb10f8fa
      mbrandy authored 
      Port 09d84535

Original commit message:
    The FastNewStrictArgumentsStub is very similar to the recently added
    FastNewRestParameterStub, it's actually almost a copy of it, except that
    it doesn't have the fast case we have for the empty rest parameter. This
    patch improves strict arguments in TurboFan and fullcodegen by up to 10x
    compared to the previous version.

    Also introduce proper JSSloppyArgumentsObject and JSStrictArgumentsObject
    for the in-object properties instead of having them as constants in the
    Heap class.

    Drive-by-fix: Use this stub and the FastNewRestParameterStub in the
    interpreter to avoid the runtime call overhead for strict arguments
    and rest parameter creation.

R=bmeurer@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com
BUG=

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

Cr-Commit-Position: refs/heads/master@{#33963}
      fb10f8fa
    • mbrandy's avatar
      PPC: [Interpreter] Save and restore dispatch table pointer during calls. · c8257c4c
      mbrandy authored 
      Port a2935d63

Original commmit message:
    Saves and restores the dispatch pointer during calls to enable the debugger to
    switch the dispatch table used by a function during it's execution.

    Also moves the accumulator and context nodes to be Variables so that they will
    be properly merged across branches.

R=rmcilroy@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com
BUG=v8:4280,v8:4690
LOG=N

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

Cr-Commit-Position: refs/heads/master@{#33962}
      c8257c4c
  47. 11 Feb, 2016 1 commit
  49. 10 Feb, 2016 1 commit
    • mbrandy's avatar
      PPC: Preserve argument count for calls. · 0c3f7e93
      mbrandy authored 
      Port 5de27c34

Original commit message:
    Calls use registers for target, new_target and argument count.
    We don't always respect argument count. It didn't bite us in the past
    because the code paths where we clobbered it never used it, though
    in future it could be an issue.

R=mvstanton@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com
BUG=

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

Cr-Commit-Position: refs/heads/master@{#33878}
      0c3f7e93
  51. 08 Feb, 2016 2 commits
    • mstarzinger's avatar
      Remove --stop-at flag from several backends. · 664110f8
      mstarzinger authored 
      The flag in question is a debug-only flag supported by full-codegen and
Crankshaft only. In it's current form there are some unresolved issues:
- The flag is defeated by inlining in Crankshaft.
- The flag is not supported by TurboFan.
- The flag is not supported by Ignition.

Instead of addressing the above issues and increasing maintenance cost
for all backends and also given the "slim" test coverage, this CL fully
removes the support from all backends.

R=bmeurer@chromium.org,jkummerow@chromium.org

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

Cr-Commit-Position: refs/heads/master@{#33817}
      664110f8
    • verwaest's avatar
      Mark maps having a hidden prototype rather than maps of hidden prototypes. · d2503c4d
      verwaest authored 
      Generally we only care whether the next object is a hidden prototype.
It's simpler to check whether the current object has a hidden prototype
instead of walking to the next prototype and checking its map.

BUG=

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

Cr-Commit-Position: refs/heads/master@{#33816}
      d2503c4d
  53. 06 Feb, 2016 1 commit
    • ishell's avatar
      [api] Make ObjectTemplate::SetNativeDataProperty() work even if the... · da213b6e
      ishell authored 
      [api] Make ObjectTemplate::SetNativeDataProperty() work even if the ObjectTemplate does not have a constructor.

Previously ObjectTemplate::New() logic relied on the fact that all the accessor properties are already installed in the initial map of the function object of the constructor FunctionTemplate.
When the FunctionTemplate were instantiated the accessors of the instance templates from the whole inheritance chain were accumulated and added to the initial map.
ObjectTemplate::SetSetAccessor() used to explicitly ensure that the ObjectTemplate has a constructor and therefore an initial map to add all accessors to.

The new approach is to add all the accessors and data properties to the object exactly when the ObjectTemplate is instantiated. In order to keep it fast we now cache the object boilerplates in the Isolate::template_instantiations_cache (the former function_cache), so the object creation turns to be a deep copying of the boilerplate object.

BUG=chromium:579009
LOG=Y

Committed: https://crrev.com/6a118774244d087b5979e9291d628a994f21d59d
Cr-Commit-Position: refs/heads/master@{#33674}

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

Cr-Commit-Position: refs/heads/master@{#33798}
      da213b6e
  55. 05 Feb, 2016 2 commits
    • yangguo's avatar
      [interpreter] move the dispatch table off heap. · 91009c50
      yangguo authored 
      This makes the dispatch table similar to the builtins code list and makes
sure that the dispatch table does not move.

R=mstarzinger@chromium.org, rmcilroy@chromium.org

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

Cr-Commit-Position: refs/heads/master@{#33781}
      91009c50
    • mvstanton's avatar
      Revert of PPC: Type Feedback Vector lives in the closure (patchset #1 id:1 of... · 14fa68a3
      mvstanton authored 
      Revert of PPC: Type Feedback Vector lives in the closure (patchset #1 id:1 of https://codereview.chromium.org/1671553002/ )

Reason for revert:
issues with chromium api natives, must revert for now, thanks.

Original issue's description:
> PPC: Type Feedback Vector lives in the closure
>
> Port bb31db3a
>
> Original commit message:
>     (RELAND: the problem before was a missing write barrier for adding the code
>     entry to the new closure. It's been addressed with a new macro instruction
>     and test. The only change to this CL is the addition of two calls to
>     __ RecordWriteCodeEntryField() in the platform CompileLazy builtin.)
>
>     We get less "pollution" of type feedback if we have one vector per native
>     context, rather than one for the whole system. This CL moves the vector
>     appropriately.
>
>     We rely more heavily on the Optimized Code Map in the SharedFunctionInfo. The
>     vector actually lives in the first slot of the literals array (indeed there is
>     great commonality between those arrays, they can be thought of as the same
>     thing). So we make greater effort to ensure there is a valid literals array
>     after compilation.
>
>     This meant, for performance reasons, that we needed to extend
>     FastNewClosureStub to support creating closures with literals. And ultimately,
>     it drove us to move the optimized code map lookup out of FastNewClosureStub
>     and into the compile lazy builtin.
>
>     The heap change is trivial so I TBR Hannes for it...
>     Also, Yang has had a look at the debugger changes already and approved 'em. So he is TBR style too.
>     And Benedikt reviewed it as well.
>
> R=mvstanton@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com
> BUG=
>
> Committed: https://crrev.com/753ad25efa4790ea7c80aceecfa223c3436ca36f
> Cr-Commit-Position: refs/heads/master@{#33753}

TBR=joransiu@ca.ibm.com,jyan@ca.ibm.com,michael_dawson@ca.ibm.com,mbrandy@us.ibm.com
# 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/1673623002

Cr-Commit-Position: refs/heads/master@{#33765}
      14fa68a3
  57. 04 Feb, 2016 2 commits
    • mbrandy's avatar
      PPC: Type Feedback Vector lives in the closure · 753ad25e
      mbrandy authored 
      Port bb31db3a

Original commit message:
    (RELAND: the problem before was a missing write barrier for adding the code
    entry to the new closure. It's been addressed with a new macro instruction
    and test. The only change to this CL is the addition of two calls to
    __ RecordWriteCodeEntryField() in the platform CompileLazy builtin.)

    We get less "pollution" of type feedback if we have one vector per native
    context, rather than one for the whole system. This CL moves the vector
    appropriately.

    We rely more heavily on the Optimized Code Map in the SharedFunctionInfo. The
    vector actually lives in the first slot of the literals array (indeed there is
    great commonality between those arrays, they can be thought of as the same
    thing). So we make greater effort to ensure there is a valid literals array
    after compilation.

    This meant, for performance reasons, that we needed to extend
    FastNewClosureStub to support creating closures with literals. And ultimately,
    it drove us to move the optimized code map lookup out of FastNewClosureStub
    and into the compile lazy builtin.

    The heap change is trivial so I TBR Hannes for it...
    Also, Yang has had a look at the debugger changes already and approved 'em. So he is TBR style too.
    And Benedikt reviewed it as well.

R=mvstanton@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com
BUG=

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

Cr-Commit-Position: refs/heads/master@{#33753}
      753ad25e
    • rmcilroy's avatar
      [Interpreter] Add explicit StackCheck bytecodes on function entry and back branches. · 1ce720f2
      rmcilroy authored 
      Moves the stack check from the function entry trampoline to instead be
after function activation using an explicit StackCheck bytecode. Also
add stack checks on back edges of loops.

BUG=v8:4280,v8:4678
LOG=N

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

Cr-Commit-Position: refs/heads/master@{#33730}
      1ce720f2
  59. 03 Feb, 2016 2 commits
    • mbrandy's avatar
      PPC: Minor improvements to MathMaxMin. · bb1d2817
      mbrandy authored 
      R=joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com
BUG=

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

Cr-Commit-Position: refs/heads/master@{#33711}
      bb1d2817
    • hablich's avatar
      Revert of [api] Make ObjectTemplate::SetNativeDataProperty() work even if the... · db47a31f
      hablich authored 
      Revert of [api] Make ObjectTemplate::SetNativeDataProperty() work even if the ObjectTemplate does not have a … (patchset #3 id:80001 of https://codereview.chromium.org/1642223003/ )

Reason for revert:
Fails a lot of layout tests and blocks the roll. Can be easily reproduced with a local Chromium checkout.

Reference: https://codereview.chromium.org/1652413003/

Original issue's description:
> [api] Make ObjectTemplate::SetNativeDataProperty() work even if the ObjectTemplate does not have a constructor.
>
> Previously ObjectTemplate::New() logic relied on the fact that all the accessor properties are already installed in the initial map of the function object of the constructor FunctionTemplate.
> When the FunctionTemplate were instantiated the accessors of the instance templates from the whole inheritance chain were accumulated and added to the initial map.
> ObjectTemplate::SetSetAccessor() used to explicitly ensure that the ObjectTemplate has a constructor and therefore an initial map to add all accessors to.
>
> The new approach is to add all the accessors and data properties to the object exactly when the ObjectTemplate is instantiated. In order to keep it fast we now cache the object boilerplates in the Isolate::template_instantiations_cache (the former function_cache), so the object creation turns to be a deep copying of the boilerplate object.
>
> This CL also prohibits non-primitive properties in ObjectTemplate to avoid potential cross-context leaks.
>
> BUG=chromium:579009
> LOG=Y
>
> Committed: https://crrev.com/6a118774244d087b5979e9291d628a994f21d59d
> Cr-Commit-Position: refs/heads/master@{#33674}

TBR=verwaest@chromium.org,ishell@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=chromium:579009

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

Cr-Commit-Position: refs/heads/master@{#33698}
      db47a31f