1. 14 Sep, 2017 2 commits
  2. 09 Sep, 2017 1 commit
    • Anisha Rohra's avatar
      s390/PPC: Make Register et al. real classes · 0b491c89
      Anisha Rohra authored
      Port 9e995e12
      Port 408f252b
      
        Up to now, each architecture defined all Register types as structs,
        with lots of redundancy. An often found comment noted that they cannot
        be classes due to initialization order problems. As these problems are
        gone with C++11 constexpr constants, I now tried making Registers
        classes again.
        All register types now inherit from RegisterBase, which provides a
        default set of methods and named constructors (like ::from_code,
        code(), bit(), is_valid(), ...).
        This design allows to guarantee an interesting property: Each register
        is either valid, or it's the no_reg register. There are no other
        invalid registers. This is guaranteed statically by the constexpr
        constructor, and dynamically by ::from_code.
      
        I decided to disallow the default constructor completely, so instead of
        "Register reg;" you now need "Register reg = no_reg;". This makes
        explicit how the Register is initialized.
      
        I did this change to the x64, ia32, arm, arm64, mips and mips64 ports.
        Overall, code got much more compact and more safe. In theory, it should
        also increase performance (since the is_valid() check is simpler), but
        this is probably not measurable.
      
      R=bjaideep@ca.ibm.com, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com
      BUG=
      LOG=N
      
      Change-Id: I2e87efc8790290c64fd6c0a2d093326710b30ed3
      Reviewed-on: https://chromium-review.googlesource.com/658065Reviewed-by: 's avatarJaideep Bajwa <bjaideep@ca.ibm.com>
      Commit-Queue: Jaideep Bajwa <bjaideep@ca.ibm.com>
      Cr-Commit-Position: refs/heads/master@{#47933}
      0b491c89
  3. 06 Sep, 2017 1 commit
    • Anisha Rohra's avatar
      s390/PPC: Remove weak-list of optimized JS functions. · 1902b5a9
      Anisha Rohra authored
      Port f0acede9
      
      This CL removes the weak-list of JS functions from the context
      and all the code that iterares over it. This list was being used
      mainly during deoptimization (for code unlinking) and during
      garbage collection. Removing it will improve performance of
      programs that create many closures and trigger many scavenge GC
      cycles.
      
      No extra work is required during garbage collection. However,
      given that we no longer unlink code from JS functions during
      deoptimization, we leave it as it is, and on its next activation
      we check whether the mark_for_deoptimization bit of that code is
      set, and if it is, than we unlink it and jump to lazy compiled
      code. This check happens in the prologue of every code object.
      
      We needed to change/remove the cctests that used to check
      something on this list.
      
      R=bjaideep@ca.ibm.com, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com
      BUG=
      LOG=N
      
      Change-Id: I8007a837d43b6a339789cfd727e81ad7f4ac3ae1
      Reviewed-on: https://chromium-review.googlesource.com/651891Reviewed-by: 's avatarJaideep Bajwa <bjaideep@ca.ibm.com>
      Commit-Queue: Jaideep Bajwa <bjaideep@ca.ibm.com>
      Cr-Commit-Position: refs/heads/master@{#47840}
      1902b5a9
  4. 04 Sep, 2017 1 commit
  5. 23 Aug, 2017 1 commit
    • Ross McIlroy's avatar
      Reland "[Compiler] Remove code aging support." · 8bf15bf1
      Ross McIlroy authored
      > This reverts commit 42d3d36b.
      > 
      > Original change's description:
      > > [Compiler] Remove code aging support.
      > > 
      > > Code aging is no longer supported by any remaining compilers now
      > > that full codegen has been removed. This CL removes all vestiges of
      > > code aging.
      > > 
      > > BUG=v8:6409
      > > 
      > > Change-Id: I945ebcc20c7c55120550c8ee36188bfa042ea65e
      > > Reviewed-on: https://chromium-review.googlesource.com/619153
      > > Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
      > > Reviewed-by: Yang Guo <yangguo@chromium.org>
      > > Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
      > > Reviewed-by: Marja Hölttä <marja@chromium.org>
      > > Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
      > > Cr-Commit-Position: refs/heads/master@{#47501}
      > 
      > TBR=ulan@chromium.org,rmcilroy@chromium.org,marja@chromium.org,yangguo@chromium.org,mstarzinger@chromium.org,rodolph.perfetta@arm.com
      > 
      > Change-Id: I9d8b2985e2d472697908270d93a35eb7ef9c88a8
      > No-Presubmit: true
      > No-Tree-Checks: true
      > No-Try: true
      > Bug: v8:6409
      > Reviewed-on: https://chromium-review.googlesource.com/625998
      > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
      > Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#47506}
      
      TBR=ulan@chromium.org,rmcilroy@chromium.org,marja@chromium.org,yangguo@chromium.org,mstarzinger@chromium.org,rodolph.perfetta@arm.com
      
      Change-Id: I68785c6be7686e874b3848103e3a34483eaeb519
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Bug: v8:6409
      Reviewed-on: https://chromium-review.googlesource.com/625919Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
      Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#47535}
      8bf15bf1
  6. 22 Aug, 2017 3 commits
  7. 21 Aug, 2017 1 commit
  8. 14 Aug, 2017 1 commit
  9. 11 Aug, 2017 1 commit
  10. 03 Aug, 2017 1 commit
  11. 02 Aug, 2017 2 commits
  12. 27 Jul, 2017 1 commit
    • Jaideep Bajwa's avatar
      PPC/s390: Switch JSFunction::code to be a tagged value. · 9836cdb1
      Jaideep Bajwa authored
      Port 4e207a42
      
      Original Commit Message:
      
          This switches the "code entry" field on JSFunction to no longer be an
          inner pointer into a Code object (i.e. to the start of the instruction
          stream), but a properly tagged pointer instead.
      
          Motivation behind this is the ability to treat this field regularly as
          part of escape analysis in the optimizing compiler. Also simplifies the
          object visitation for JSFunction objects.
      
      R=mstarzinger@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com
      BUG=
      LOG=N
      
      Change-Id: Ifa5998551e041c8de647df7306dd549455936699
      Reviewed-on: https://chromium-review.googlesource.com/588468Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
      Commit-Queue: Jaideep Bajwa <bjaideep@ca.ibm.com>
      Cr-Commit-Position: refs/heads/master@{#46934}
      9836cdb1
  13. 26 Jul, 2017 4 commits
  14. 25 Jul, 2017 1 commit
  15. 24 Jul, 2017 2 commits
  16. 20 Jul, 2017 1 commit
  17. 19 Jul, 2017 1 commit
  18. 10 Jul, 2017 1 commit
    • Enrico Bacis's avatar
      [ppc] use Double instead of double in ppc compiler · 5457e8a9
      Enrico Bacis authored
      The use of double variables to store bit patterns may lead to bit flips
      when the stored bit pattern is a signaling NaN (sNaN). Operations on a
      sNaN variable (even just returning the variable from a function) may
      turn it into a quiet NaN (qNaN), flipping the signaling bit and
      affecting the information stored in the variable.
      
      We observed this behaviour on ia32 architectures and therefore in the
      simulator builds for other platforms. The use of the wrapper class
      Double should prevent this behaviour.
      
      R=ahaas@chromium.org
      
      Change-Id: Ibd1119924a59db771fd4c250689ad9c2a35fff75
      Reviewed-on: https://chromium-review.googlesource.com/562771Reviewed-by: 's avatarJaideep Bajwa <bjaideep@ca.ibm.com>
      Reviewed-by: 's avatarAndreas Haas <ahaas@chromium.org>
      Commit-Queue: Enrico Bacis <enricobacis@google.com>
      Cr-Commit-Position: refs/heads/master@{#46533}
      5457e8a9
  19. 06 Jul, 2017 1 commit
  20. 05 Jul, 2017 1 commit
  21. 03 Jul, 2017 1 commit
  22. 23 Jun, 2017 1 commit
  23. 09 Jun, 2017 1 commit
    • bjaideep's avatar
      PPC/s390: [builtins] Start refactoring the Apply builtin. · 9385fd40
      bjaideep authored
      Port af76779a
      
      Original Commit Message:
      
          This splits the monolithic Apply builtin into several smaller builtins,
          namely CallVargargs and ConstructVarargs, which accept a length and a
          FixedArray of elements and deal with the actual stack manipulation, and
          CallWithArrayLike / ConstructWithArrayLike that deal with getting the
          elements from the receiver (for Function.prototype.apply, Reflect.apply
          and Reflect.construct), which can now be written using the CSA.
      
          The idea is that these builtins can be reused by TurboFan directly in
          the future when we optimize apply better, and that we can also reuse the
          core logic in the handling of spread calls/constructs.
      
      R=bmeurer@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com
      BUG=v8:4587,v8:5269
      LOG=N
      
      Review-Url: https://codereview.chromium.org/2932833002
      Cr-Commit-Position: refs/heads/master@{#45826}
      9385fd40
  24. 29 Mar, 2017 2 commits
    • bjaideep's avatar
      PPC/s390: [cleanup] combine 3 ResumeGenerator stubs into one · 411efc16
      bjaideep authored
      Port 5615e5b8
      
      Original Commit Message:
      
          This hopefully shrinks binary size a bit, at the cost of (slightly)
          increasing the complexity of the ResumeGenerator stub. Includes ia32,
          x64, mips, mips64, arm and arm64 ports.
      
      R=caitp@igalia.com, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com
      BUG=v8:5855
      LOG=N
      
      Review-Url: https://codereview.chromium.org/2783043002
      Cr-Commit-Position: refs/heads/master@{#44253}
      411efc16
    • bjaideep's avatar
      PPC/s390: [async-iteration] implement AsyncGenerator · a857e3d0
      bjaideep authored
      Port bf463c4d
      
      Original Commit Message:
      
          - Introduce new struct AsyncGeneratorRequest, which holds
            information pertinent to resuming execution of an
            AsyncGenerator, such as the Promise associated with the async
            generator request. It is intended to be used as a singly
            linked list, and holds a pointer to the next item in te queue.
      
          - Introduce JSAsyncGeneratorObject (subclass of
            JSGeneratorObject), which includes several new internal fields
            (`queue` which contains a singly linked list of
            AsyncGeneratorRequest objects, and `await_input` which
            contains the sent value from an Await expression (This is
            necessary to prevent function.sent (used by yield*) from
            having the sent value observably overwritten during
            execution).
      
          - Modify SuspendGenerator to accept a set of Flags, which
            indicate whether the suspend is for a Yield or Await, and
            whether it takes place on an async generator or ES6
            generator.
      
          - Introduce interpreter intrinsics and TF intrinsic lowering for
            accessing the await input of an async generator
      
          - Modify the JSGeneratorStore operator to understand whether or
            not it's suspending for a normal yield, or an AsyncGenerator
            Await. This ensures appropriate registers are stored.
      
          - Add versions of ResumeGeneratorTrampoline which store the
            input value in a different field depending on wether it's an
            AsyncGenerator Await resume, or an ordinary resume. Also modifies
            whether debug code will assert that the generator object is a
            JSGeneratorObject or a JSAsyncGeneratorObject depending on the
            resume type.
      
      R=caitp@igalia.com, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com
      BUG=v8:5855
      LOG=N
      
      Review-Url: https://codereview.chromium.org/2780283002
      Cr-Commit-Position: refs/heads/master@{#44247}
      a857e3d0
  25. 24 Mar, 2017 1 commit
    • Jochen Eisinger's avatar
      Revert "Remove ClassOf intrinsic from FCG and CS" · d0c2b8c4
      Jochen Eisinger authored
      This reverts commit f20261bf.
      
      Reason for revert: We need the GetMapConstructor instruction for CallApiCallbackStub
      
      Original change's description:
      > Remove ClassOf intrinsic from FCG and CS
      > 
      > I plan to change the constructor field of maps, and instead of patching
      > the intrinsics all over the place, just fall back to the runtime.
      > 
      > R=​bmeurer@chromium.org
      > BUG=v8:6084
      > 
      > Change-Id: Ie294b74ab615fd794d7fc47488e2e30e2b49b4db
      > Reviewed-on: https://chromium-review.googlesource.com/454616
      > Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
      > Commit-Queue: Jochen Eisinger <jochen@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#43765}
      
      TBR=jochen@chromium.org,bmeurer@chromium.org,adamk@chromium.org,hablich@chromium.org,v8-reviews@googlegroups.com,v8-mips-ports@googlegroups.com,v8-ppc-ports@googlegroups.com,v8-x87-ports@googlegroups.com
      # Not skipping CQ checks because original CL landed > 1 day ago.
      BUG=v8:6084
      
      Change-Id: I06f60d409eccb4ad3abad14f5c9782bfe9122aea
      Reviewed-on: https://chromium-review.googlesource.com/458379Reviewed-by: 's avatarJochen Eisinger <jochen@chromium.org>
      Commit-Queue: Jochen Eisinger <jochen@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#44106}
      d0c2b8c4
  26. 22 Mar, 2017 1 commit
  27. 17 Mar, 2017 1 commit
    • neis's avatar
      Disentangle assembler from isolate. · 94b088ca
      neis authored
      This is a first step towards moving Turbofan code generation off the main thread.
      
      Summary of the changes:
      - AssemblerBase no longer has a pointer to the isolate. Instead, its
        constructor receives the few things that it needs from the isolate (on most
        architectures this is just the serializer_enabled flag).
      - RelocInfo no longer has a pointer to the isolate. Instead, the functions
        that need it take it as an argument.  (There are currently still a few that
        implicitly access the isolate through a HeapObject.)
      - The MacroAssembler now explicitly holds a pointer to the isolate (before, it
        used to get it from the Assembler).
      - The jit_cookie also moved from AssemblerBase to the MacroAssemblers, since
        it's not used at all in the Assemblers.
      - A few architectures implemented parts of the Assembler with the help
        of a Codepatcher that is based on MacroAssembler.  Since the Assembler no
        longer has the isolate, but the MacroAssembler still needs it, this doesn't
        work anymore.  Instead, these Assemblers now use a new PatchingAssembler.
      
      BUG=v8:6048
      
      Review-Url: https://codereview.chromium.org/2732273003
      Cr-Commit-Position: refs/heads/master@{#43890}
      94b088ca
  28. 14 Mar, 2017 1 commit
  29. 22 Feb, 2017 1 commit
  30. 09 Feb, 2017 1 commit
  31. 08 Feb, 2017 1 commit