1. 29 May, 2018 1 commit
  2. 26 Jun, 2017 1 commit
    • hans's avatar
      Make some functions that are hit during renderer startup available for inlining · 777da354
      hans authored
      This is towards closing the perf gap between the MSVC build (which uses link-
      time optimization) and Clang (where LTO isn't ready on Windows yet). We did
      a study (see bug) to see which non-inlined functions are hit a lot during render
      start-up, and which would be inlined during LTO. This should benefit performance
      in all builds which currently don't use LTO (Android, Linux, Mac) as well as
      the Win/Clang build.
      
      The binary size of chrome_child.dll increases by 2KB with this.
      
      BUG=chromium:728324
      CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_chromium_compile_dbg_ng;master.tryserver.chromium.mac:mac_chromium_compile_dbg_ng
      
      Review-Url: https://codereview.chromium.org/2950993002
      Cr-Commit-Position: refs/heads/master@{#46229}
      777da354
  3. 25 Jun, 2017 1 commit
  4. 23 Jun, 2017 1 commit
    • hans's avatar
      Make some functions that are hit during renderer startup available for inlining · d00d52be
      hans authored
      This is towards closing the perf gap between the MSVC build (which uses link-
      time optimization) and Clang (where LTO isn't ready on Windows yet). We did
      a study (see bug) to see which non-inlined functions are hit a lot during render
      start-up, and which would be inlined during LTO. This should benefit performance
      in all builds which currently don't use LTO (Android, Linux, Mac) as well as
      the Win/Clang build.
      
      The binary size of chrome_child.dll increases by 2KB with this.
      
      BUG=chromium:728324
      
      Review-Url: https://codereview.chromium.org/2950993002
      Cr-Commit-Position: refs/heads/master@{#46191}
      d00d52be
  5. 22 Jun, 2017 1 commit
  6. 08 May, 2017 1 commit
    • Adam Klein's avatar
      Skip hole initialization of lexical variables when possible · ededfcd2
      Adam Klein authored
      This patch expands scope analysis to skip hole initialization
      when it can be determined statically that no hole checks will
      be generated at runtime.
      
      Two conditions must be met to safely eliminate hole initialization:
        - There must not exist a VariableProxy referencing this Variable
          whose HoleCheckMode is kRequired
        - The Variable must be stack allocated; any other allocation implies
          that it may be accessed from not-yet-analyzed scopes (other modules,
          inner functions, or eval code) and that code may require
          hole checks.
      
      The new logic required removing debug code in full-codegen which is
      now incorrect in some cases.
      
      Also fixed Variable's bitfield helpers to take no more space than needed.
      
      Bug: chromium:651637
      Change-Id: Ie5ac326af4e05b7a5c3c37cd4d0afba6a51a504d
      Reviewed-on: https://chromium-review.googlesource.com/494006
      Commit-Queue: Adam Klein <adamk@chromium.org>
      Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
      Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#45170}
      ededfcd2
  7. 10 Feb, 2017 1 commit
  8. 09 Jan, 2017 1 commit
  9. 03 Nov, 2016 1 commit
    • verwaest's avatar
      Turn Scope::locals_ into a ThreadedList · 4fa2ebcb
      verwaest authored
      This turns the ZoneList with minimum 6 words overhead into a linked list through variables, using 2 words for the empty list. Additionally the average number of pointers per entry goes down to the optimal 1 per variable that's in a list.
      
      This does introduce 1 pointer unnecessary overhead for dynamic variables. If that becomes a problem we could distinguish between variables in lists and variables not in lists. We can distinguish them at construction-time.
      
      BUG=v8:5209
      
      Review-Url: https://codereview.chromium.org/2475433002
      Cr-Commit-Position: refs/heads/master@{#40714}
      4fa2ebcb
  10. 07 Oct, 2016 1 commit
  11. 09 Sep, 2016 1 commit
  12. 31 Aug, 2016 1 commit
    • adamk's avatar
      Remove CONST_LEGACY VariableMode · 7516fe1e
      adamk authored
      The only remaining use of this VariableMode is for the names of sloppy
      named function expressions. This patch instead uses CONST for such
      bindings (just as we do in strict mode) and instead marks those
      Variables specially. During code generation a new helper method,
      Variable::throw_on_const_assignment(), is called to decide whether
      to throw or silently ignore the assignment.
      
      Review-Url: https://codereview.chromium.org/2233673003
      Cr-Commit-Position: refs/heads/master@{#39052}
      7516fe1e
  13. 26 Aug, 2016 1 commit
  14. 25 Aug, 2016 1 commit
  15. 18 Aug, 2016 1 commit
  16. 16 Aug, 2016 2 commits
  17. 12 Aug, 2016 1 commit
  18. 08 Aug, 2016 1 commit
  19. 18 Jul, 2016 1 commit
    • neis's avatar
      [modules] AST and parser rework. · 0e000a87
      neis authored
      Highlights:
      - Record all imports and exports in the ModuleDescriptor.
      - Remove ImportDeclaration; instead, introduce a new variable kind for imports.
      - Set name on default exported anonymous functions.
      
      Still to do: declaration of namespace imports.
      
      BUG=v8:1569
      
      Review-Url: https://codereview.chromium.org/2108193003
      Cr-Commit-Position: refs/heads/master@{#37815}
      0e000a87
  20. 30 Jun, 2016 1 commit
  21. 20 Jun, 2016 1 commit
    • adamk's avatar
      [cleanup] Remove dead code from DeclareLookupSlot and rename it · cbc6adc8
      adamk authored
      Runtime_DeclareLookupSlot is used when generating code for var and function declarations
      originating in an eval. Over time, it's accumulated quite a bit of cruft, which this CL removes:
      
        - With legacy const gone, lookup slots never have any property attributes.
        - There was a bit signaling that the variable was from an eval, but that was redundant since
          DeclareLookupSlot is only used for eval.
        - Some Proxy-related code didn't make sense here.
      
      Its name was also not terribly clear: while "LookupSlot" is used in several places, this
      particular function is only used for declaring variables and functions inside sloppy eval.
      Renamed (and split into two) to make this clear for future archeologists.
      
      Also added various DCHECKs to check the assumptions being made.
      
      Review-Url: https://codereview.chromium.org/2061173002
      Cr-Commit-Position: refs/heads/master@{#37111}
      cbc6adc8
  22. 19 Apr, 2016 1 commit
    • adamk's avatar
      Remove all non-function-name uses of CONST_LEGACY · 59546149
      adamk authored
      Now that all 'const' declarations are of the ES2015 variety, the only
      use of CONST_LEGACY is for function name bindings in sloppy mode
      named function expressions.
      
      This patch aims to delete all code meant to handle other cases, which
      mostly had to do with hole initialization/hole checks. Since function
      name bindings are initialized at entry to a function, it's impossible
      to ever observe one in an uninitialized state.
      
      To simplify the patch further, it removes the `IMPORT` VariableMode,
      as it's not likely to be needed (IMPORT is identical to CONST for
      the purpose of VariableMode).
      
      Review URL: https://codereview.chromium.org/1895973002
      
      Cr-Commit-Position: refs/heads/master@{#35632}
      59546149
  23. 18 Feb, 2016 1 commit
  24. 26 Nov, 2015 1 commit
  25. 12 Oct, 2015 1 commit
    • littledan's avatar
      Test for var declarations in eval which conflict with let · d515e513
      littledan authored
      Previously, name conflicts between var and let declarations were only
      made into exceptions if they were visible at parse-time. This patch adds
      runtime checks so that sloppy-mode direct eval can't introduce conflicting
      var declarations. The change is implemented by traversing the scope chain
      when a direct eval introduces a var declaration to look for conflicting
      let declarations, up to the function boundary.
      
      BUG=v8:4454
      R=adamk
      LOG=Y
      
      Review URL: https://codereview.chromium.org/1382513003
      
      Cr-Commit-Position: refs/heads/master@{#31211}
      d515e513
  26. 14 Aug, 2015 1 commit
  27. 23 Jul, 2015 1 commit
  28. 15 Jul, 2015 1 commit
  29. 06 Jul, 2015 1 commit
  30. 01 Jun, 2015 1 commit
  31. 19 May, 2015 2 commits
  32. 18 May, 2015 1 commit
  33. 13 May, 2015 1 commit
  34. 11 May, 2015 1 commit
  35. 07 May, 2015 1 commit
    • machenbach's avatar
      Revert of Resolve references to "this" the same way as normal variables... · 5cab6be8
      machenbach authored
      Revert of Resolve references to "this" the same way as normal variables (patchset #2 id:20001 of https://codereview.chromium.org/1130733003/)
      
      Reason for revert:
      [Sheriff] Breaks jetstream benchmark with errors like this:
      
      >>> Running suite: JetStream/bigfib.cpp
      >>> Stdout (#1):
      undefined:93: ReferenceError: this is not defined
        this['Module'] = Module;
        ^
      ReferenceError: this is not defined
          at eval (eval at __run (runner.js:13:3), <anonymous>:93:3)
          at eval (native)
          at __run (runner.js:13:3)
          at Object.runSimpleBenchmark (runner.js:44:31)
          at runner.js:97:13
      
      Original issue's description:
      > Resolve references to "this" the same way as normal variables
      >
      > Make the parser handle references to "this" as unresolved variables, so the
      > same logic as for the rest of function parameters is used for the receiver.
      > Minor additions to the code generation handle copying the receiver to the
      > context, along with the rest of the function parameters.
      >
      > Based on work by Adrian Perez de Castro <aperez@igalia.com>.
      >
      > BUG=v8:2700
      > LOG=N
      >
      > Committed: https://crrev.com/06a792b7cc2db33ffce7244c044a9c05afbb6116
      > Cr-Commit-Position: refs/heads/master@{#28263}
      
      TBR=rossberg@chromium.org,arv@chromium.org,wingo@igalia.com
      NOPRESUBMIT=true
      NOTREECHECKS=true
      NOTRY=true
      BUG=v8:2700
      
      Review URL: https://codereview.chromium.org/1129723003
      
      Cr-Commit-Position: refs/heads/master@{#28283}
      5cab6be8
  36. 06 May, 2015 1 commit
    • wingo's avatar
      Resolve references to "this" the same way as normal variables · 06a792b7
      wingo authored
      Make the parser handle references to "this" as unresolved variables, so the
      same logic as for the rest of function parameters is used for the receiver.
      Minor additions to the code generation handle copying the receiver to the
      context, along with the rest of the function parameters.
      
      Based on work by Adrian Perez de Castro <aperez@igalia.com>.
      
      BUG=v8:2700
      LOG=N
      
      Review URL: https://codereview.chromium.org/1130733003
      
      Cr-Commit-Position: refs/heads/master@{#28263}
      06a792b7
  37. 05 May, 2015 2 commits
    • wingo's avatar
      Revert of Resolve references to "this" the same way as normal variables... · 1e4173d9
      wingo authored
      Revert of Resolve references to "this" the same way as normal variables (patchset #11 id:240001 of https://codereview.chromium.org/1097283003/)
      
      Reason for revert:
      nosnap failures
      
      Original issue's description:
      > Resolve references to "this" the same way as normal variables
      >
      > Make the parser handle references to "this" as unresolved variables, so the
      > same logic as for the rest of function parameters is used for the receiver.
      > Minor additions to the code generation handle copying the receiver to the
      > context, along with the rest of the function parameters.
      >
      > Based on work by Adrian Perez de Castro <aperez@igalia.com>.
      >
      > BUG=
      > LOG=N
      >
      > Committed: https://crrev.com/18619d355192e2699203d12d9ebb9caea107b693
      > Cr-Commit-Position: refs/heads/master@{#28236}
      
      TBR=rossberg@chromium.org,mstarzinger@chromium.org,dslomov@chromium.org,adamk@chromium.org,arv@chromium.org
      NOPRESUBMIT=true
      NOTREECHECKS=true
      NOTRY=true
      BUG=
      
      Review URL: https://codereview.chromium.org/1113133006
      
      Cr-Commit-Position: refs/heads/master@{#28238}
      1e4173d9
    • wingo's avatar
      Resolve references to "this" the same way as normal variables · 18619d35
      wingo authored
      Make the parser handle references to "this" as unresolved variables, so the
      same logic as for the rest of function parameters is used for the receiver.
      Minor additions to the code generation handle copying the receiver to the
      context, along with the rest of the function parameters.
      
      Based on work by Adrian Perez de Castro <aperez@igalia.com>.
      
      BUG=
      LOG=N
      
      Review URL: https://codereview.chromium.org/1097283003
      
      Cr-Commit-Position: refs/heads/master@{#28236}
      18619d35