1. 09 Sep, 2015 1 commit
  2. 01 Sep, 2015 1 commit
  3. 31 Aug, 2015 1 commit
    • mstarzinger's avatar
      [turbofan] Remove usage of Unique<T> from graph. · 6e65e6db
      mstarzinger authored
      The usage of Unique<T> throughout the TurboFan IR does not have any
      advantage. There is no single point in time when they are initialized
      and most use-sites looked through to the underlying Handle<T> anyways.
      Also there already was a mixture of Handle<T> versus Unique<T> in the
      graph and this unifies the situation to use Handle<T> everywhere.
      
      R=bmeurer@chromium.org,titzer@chromium.org
      
      Review URL: https://codereview.chromium.org/1314473007
      
      Cr-Commit-Position: refs/heads/master@{#30458}
      6e65e6db
  4. 24 Jul, 2015 1 commit
  5. 20 Jul, 2015 2 commits
    • danno's avatar
      [turbofan]: Add a context relaxation Reducer · cca5e74a
      danno authored
      In many cases, the context that TurboFan's ASTGraphBuilder or subsequent
      reduction operations attaches to nodes does not need to be that exact
      context, but rather only needs to be one with the same native context,
      because it is used internally only to fetch the native context, e.g. for
      creating and throwing exceptions.
      
      This reducer recognizes common cases where the context that is specified
      for a node can be relaxed to a canonical, less specific one. This
      relaxed context can either be the enclosing function's context or a specific
      Module or Script context that is explicitly created within the function.
      
      This optimization is especially important for TurboFan-generated code stubs
      which use context specialization and inlining to generate optimal code.
      Without context relaxation, many extraneous moves are generated to pass
      exactly the right context to internal functions like ToNumber and
      AllocateHeapNumber, which only need the native context. By turning context
      relaxation on, these moves disappear because all these common internal
      context uses are unified to the context passed into the stub function, which
      is typically already in the correct context register and remains there for
      short stubs. It also eliminates the explicit use of a specialized context
      constant in the code stub in these cases, which could cause memory leaks.
      
      Review URL: https://codereview.chromium.org/1244583003
      
      Cr-Commit-Position: refs/heads/master@{#29763}
      cca5e74a
    • yangguo's avatar
      Debugger: prepare code for debugging on a per-function basis. · 35c28ce0
      yangguo authored
      Prior to this patch, we enter a global debug mode whenever a break point
      is set. By entering this mode, all code is deoptimized and activated
      frames are recompiled and redirected to newly compiled debug code.
      
      After this patch, we only deoptimize/redirect for functions we want to
      debug. Trigger for this is Debug::EnsureDebugInfo, and having DebugInfo
      object attached to the SFI prevents optimization/inlining.
      
      The result is that we can have optimized code for functions without break
      points alongside functions that do have break points, which are not
      optimized.
      
      R=mstarzinger@chromium.org, ulan@chromium.org
      BUG=v8:4132
      LOG=Y
      
      Review URL: https://codereview.chromium.org/1233073005
      
      Cr-Commit-Position: refs/heads/master@{#29758}
      35c28ce0
  6. 06 Jul, 2015 1 commit
  7. 30 Jun, 2015 3 commits
  8. 23 Jun, 2015 1 commit
  9. 19 Jun, 2015 2 commits
    • bmeurer's avatar
      [ubsan] Fix HeapObjectMatcher to avoid invalid casts. · 1021ed85
      bmeurer authored
      BUG=v8:3809
      LOG=n
      R=svenpanne@chromium.org
      
      Review URL: https://codereview.chromium.org/1196623002
      
      Cr-Commit-Position: refs/heads/master@{#29147}
      1021ed85
    • bmeurer's avatar
      [turbofan] Proper dead code elimination as regular reducer. · 733a2463
      bmeurer authored
      The three different concerns that the ControlReducer used to deal with
      are now properly separated into
      
        a.) DeadCodeElimination, which is a regular AdvancedReducer, that
            propagates Dead via control edges,
        b.) CommonOperatorReducer, which does strength reduction on common
            operators (i.e. Branch, Phi, and friends), and
        c.) GraphTrimming, which removes dead->live edges from the graph.
      
      This will make it possible to run the DeadCodeElimination together with
      other passes that actually introduce Dead nodes, i.e. typed lowering;
      and it opens the door for general inlining without two stage fix point
      iteration.
      
      To make the DeadCodeElimination easier and more uniform, we basically
      reverted the introduction of DeadValue and DeadEffect, and changed the
      Dead operator to produce control, value and effect. Note however that
      this is not a requirement, but merely a way to make dead propagation
      easier and more uniform. We could always go back and decide to have
      different Dead operators if some other change requires that.
      
      Note that there are several additional opportunities for cleanup now,
      i.e. OSR deconstruction could be a regular reducer now, and we don't
      need to use TheHole as dead value marker in the GraphReducer. And we can
      actually run the dead code elimination together with the other passes
      instead of using separate passes over the graph.  We will do this in
      follow up CLs.
      
      R=jarin@chromium.org, mstarzinger@chromium.org
      
      Review URL: https://codereview.chromium.org/1193833002
      
      Cr-Commit-Position: refs/heads/master@{#29146}
      733a2463
  10. 18 Jun, 2015 1 commit
  11. 11 Jun, 2015 3 commits
  12. 10 Jun, 2015 1 commit
  13. 08 Jun, 2015 1 commit
  14. 05 Jun, 2015 1 commit
    • mstarzinger's avatar
      [turbofan] Allow ReplaceWithValue to kill control. · 8f4d9a0a
      mstarzinger authored
      This allows any AdvancedReducer to remove exception projections from
      graphs. This is the common case when JS-operators are being replaced
      with pure values. The old NodeProperties::ReplaceWithValue is being
      deprecated in favor of AdvancedReducer::ReplaceWithValue.
      
      R=titzer@chromium.org
      TEST=unittests/AdvancedReducerTest
      
      Review URL: https://codereview.chromium.org/1168693002
      
      Cr-Commit-Position: refs/heads/master@{#28810}
      8f4d9a0a
  15. 27 May, 2015 1 commit
  16. 26 May, 2015 2 commits
  17. 21 May, 2015 2 commits
  18. 20 May, 2015 1 commit
  19. 19 May, 2015 1 commit
  20. 15 May, 2015 1 commit
  21. 12 May, 2015 1 commit
  22. 11 May, 2015 1 commit
    • arv's avatar
      [strong] Check arity of functions · 3226e980
      arv authored
      In strong mode it is an error to call a function with too few
      arguments.
      
      This is enforced inside the ArgumentsAdaptorTrampoline.
      
      This does not yet handle rest parameters
      
      BUG=v8:3956
      LOG=N
      R=rossberg@chromium.org, dslomov@chromium.org
      
      Review URL: https://codereview.chromium.org/1115263004
      
      Cr-Commit-Position: refs/heads/master@{#28346}
      3226e980
  23. 23 Apr, 2015 1 commit
    • bmeurer's avatar
      [turbofan] Unify frame state inputs. · 4940c0bd
      bmeurer authored
      Now all nodes that care about deoptimization always take frame state
      inputs no matter whether deoptimization is enabled for a particular
      function. In case that deoptimization is off, the AstGraphBuilder just
      inserts the empty frame state. This greatly simplifies the logic in
      various places and makes testing easier as well, and is probably the
      first step towards enabling --turbo-deoptimization by default.
      
      There seems to be no noticable performance impact on asm.js programs.
      
      Also fix the graph replay in order to regenerate the scheduler unittests.
      
      Review URL: https://codereview.chromium.org/1106613003
      
      Cr-Commit-Position: refs/heads/master@{#28026}
      4940c0bd
  24. 22 Apr, 2015 1 commit
  25. 24 Mar, 2015 2 commits
  26. 17 Mar, 2015 1 commit
  27. 10 Mar, 2015 1 commit
    • bmeurer's avatar
      [turbofan] Context specialize during inlining. · a556a104
      bmeurer authored
      Context specialization enables inlining (at least currently it is the
      only enabler for inlining), but inlining enables more possibilities for
      context specialization. So we really need to run them together.
      
      This is especially important with the "module based builtins" that we're
      working towards.
      
      BUG=v8:3952
      LOG=n
      
      Review URL: https://codereview.chromium.org/988423004
      
      Cr-Commit-Position: refs/heads/master@{#27085}
      a556a104
  28. 09 Mar, 2015 4 commits
    • titzer's avatar
      Extract ParseInfo from CompilationInfo. · 0f670256
      titzer authored
      Rationale: separate the inputs and outputs of parsing + analysis from the business of compiling (i.e. generating machine code).
      
      BUG=
      
      Review URL: https://codereview.chromium.org/974213002
      
      Cr-Commit-Position: refs/heads/master@{#27078}
      0f670256
    • Benedikt Meurer's avatar
      [turbofan] Make inlining independent of typing. · eacd6d8b
      Benedikt Meurer authored
      The JSInliner used to load the context from the JSFunction node at
      runtime, which introduced a HeapConstant (because we had to materialize
      the JSFunction after context specialization) and a LoadField operation,
      independent whether the inlinee actually uses the context. This is
      rather cumbersome currently, and therefore this is now changed to just
      embed the context constant instead. Once we do inlining based on
      SharedFunctionInfo rather than JSFunction, we should reconsider this
      decision and come up with a proper heuristic.
      
      BUG=v8:3952
      LOG=n
      R=mstarzinger@chromium.org
      
      Review URL: https://codereview.chromium.org/994523002
      
      Cr-Commit-Position: refs/heads/master@{#27069}
      eacd6d8b
    • Jaroslav Sevcik's avatar
      [turbofan] Add an extra frame state for deoptimization before binary op. · 02e31851
      Jaroslav Sevcik authored
      BUG=
      R=bmeurer@chromium.org
      
      Review URL: https://codereview.chromium.org/983153002
      
      Cr-Commit-Position: refs/heads/master@{#27060}
      02e31851
    • Benedikt Meurer's avatar
      [turbofan] Add support for inlining of builtins. · 25895aee
      Benedikt Meurer authored
      We mark certain builtins for inlining, and those should always be
      inlined into optimized code (CrankShaft already handles it this way), so
      we should support that in TurboFan as well. Currently this mainly
      affects a certain set of Math functions, but once have the basics in
      place we can extend this to any kind of builtin/code stub/accessor.
      
      This adds a new flag --turbo_builtin_inlining (enabled by default), that
      forces the inliner to always inline builtins marked for inlining, but
      does not affect inlining of other functions (this is still controlled by
      the --turbo-inlining flag).
      
      BUG=v8:3952
      LOG=n
      R=jarin@chromium.org
      
      Review URL: https://codereview.chromium.org/993473002
      
      Cr-Commit-Position: refs/heads/master@{#27059}
      25895aee