1. 10 May, 2016 2 commits
    • hpayer's avatar
      [crankshaft] Fragmentation-free allocation folding. · 61f5fbbb
      hpayer authored
      The new allocation folding implementation avoids fragmentation between folded allocation. As a consequence, our heap will always be iterable i.e. we do not have to perform a garbage collection before iterating the heap.
      
      BUG=chromium:580959
      LOG=n
      
      Review-Url: https://codereview.chromium.org/1899813003
      Cr-Commit-Position: refs/heads/master@{#36133}
      61f5fbbb
    • bmeurer's avatar
      [turbofan] Initial version of allocation folding and write barrier elimination. · b8229ec4
      bmeurer authored
      This adds a new pass MemoryOptimizer that walks over the effect chain
      from Start and lowers all Allocate, LoadField, StoreField, LoadElement,
      and StoreElement nodes, trying to fold allocations into allocation
      groups and eliminate write barriers on StoreField and StoreElement if
      possible (i.e. if the object belongs to the current allocation group and
      that group allocates in new space).
      
      R=hpayer@chromium.org, jarin@chromium.org
      BUG=v8:4931, chromium:580959
      LOG=n
      
      Review-Url: https://codereview.chromium.org/1963583004
      Cr-Commit-Position: refs/heads/master@{#36128}
      b8229ec4
  2. 09 May, 2016 2 commits
  3. 06 May, 2016 2 commits
  4. 05 May, 2016 3 commits
  5. 03 May, 2016 2 commits
  6. 29 Apr, 2016 1 commit
  7. 27 Apr, 2016 1 commit
  8. 26 Apr, 2016 2 commits
  9. 25 Apr, 2016 2 commits
  10. 22 Apr, 2016 1 commit
  11. 21 Apr, 2016 1 commit
  12. 20 Apr, 2016 2 commits
  13. 19 Apr, 2016 4 commits
  14. 18 Apr, 2016 5 commits
  15. 15 Apr, 2016 3 commits
    • rmcilroy's avatar
      [Interpreter] No longer require context machine register in bytecode handlers · 6dca3193
      rmcilroy authored
      The current context is stored as a stack slot on the interpreter frame
      and therefore we don't need to also maintain a machine register for the
      context. Removes this register from bytecode handlers.
      
      In the process modifies this frees up a register on ia32 to keep the
      dispatch table pointer in a register rather than on a stack slot on
      ia32.
      
      BUG=v8:4280
      LOG=N
      
      Review URL: https://codereview.chromium.org/1887493004
      
      Cr-Commit-Position: refs/heads/master@{#35511}
      6dca3193
    • zhengxing.li's avatar
      X87: [generators] Decouple generator resume from fullcodegen. · 0e8d220e
      zhengxing.li authored
        port 974721c6 (r35283)
      
        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.
      
      BUG=
      
      Review URL: https://codereview.chromium.org/1889083002
      
      Cr-Commit-Position: refs/heads/master@{#35510}
      0e8d220e
    • zhengxing.li's avatar
      X87: [ia32] Byte and word memory operands in ia32 cmp/test. · 39c39b54
      zhengxing.li authored
        port 3dd3beb0 (r35199)
      
        original commit message:
        Currently, if the size of two cmp or test operands is a byte or a word, we sign-extend or zero-extend each of them into a 32-bit register before doing the comparison, even when the conditions
        for the use of a memory operand are met.
      
        This CL makes it possible to load only one of them into a register and address the other as a memory operand.
      
        The tricky bit is that, unlike as in the x64 counterpart http://crrev.com/1780193003, not all registers can be accessed as bytes.
      
      BUG=
      
      Review URL: https://codereview.chromium.org/1883373002
      
      Cr-Commit-Position: refs/heads/master@{#35508}
      39c39b54
  16. 14 Apr, 2016 1 commit
    • zhengxing.li's avatar
      X87: [Interpreter] Changes GenerateDoubleToObject to push and pop rsi value. · a0d2f240
      zhengxing.li authored
        port e6b6e554 (r35163)
      
        original commit message:
        In the earlier implementation of GenerateDoubleToObject the context
        is loaded from the parent's frame. rsi is clobbered because it is used
        to store kHoleNan constnat. It is not always safe to peek at
        the parents frame. Bytecode handlers have TypedFrame and the type of
        frame is stored at FP + 1. GenerateDoubleToObject expects context
        to be store at that place. In the current implementation rsi is pushed
        onto the stack and is popped when exiting this function.
      
      BUG=
      
      Review URL: https://codereview.chromium.org/1884873007
      
      Cr-Commit-Position: refs/heads/master@{#35478}
      a0d2f240
  17. 12 Apr, 2016 2 commits
  18. 11 Apr, 2016 2 commits
  19. 08 Apr, 2016 2 commits
    • jfb's avatar
      Revert of Fix printf formats (patchset #8 id:140001 of... · 4c4fdc2d
      jfb authored
      Revert of Fix printf formats (patchset #8 id:140001 of https://codereview.chromium.org/1869433004/ )
      
      Reason for revert:
      One small issue easily fixed here: https://codereview.chromium.org/1867333003/
      
      But it looks like MSVS 2013 doesn't like some of the formats and exists with the unhelpful:
      Stderr:
      f:\dd\vctools\crt\crtw32\stdio\output.c(1125) : Assertion failed: ("Incorrect
      format specifier", 0)
      
      It's easier to revert for now, I'll dig more into the docs:
      https://msdn.microsoft.com/en-us/library/56e442dc(v=vs.120).aspx
      https://msdn.microsoft.com/en-us/library/tcxf1dw6(v=vs.120).aspx
      
      And then resubmit, making sure I run these bots.
      
      Original issue's description:
      > Fix printf formats
      >
      > The usage of __attribute__((format(x, y)) was either wrong or missing from multiple functions, leading to erroneous formats. This CL:
      >
      >  - Imports PRINTF_FORMAT macro from Chrome's src/base/compiler-specific.h.
      >  - Uses it appropriately.
      >  - Imports Chrome's base/format_macros.h mainly to fix size_t formats (further cleanup could be done).
      >  - Fixes a bunch of incorrect formats.
      >
      > R= jochen@chromium.org, bmeurer@chromium.org, yangguo@chromium.org, ahaas@chromium.org
      >
      > Committed: https://crrev.com/6ebf9fbb93d31f9be41156a3325d58704ed4933d
      > Cr-Commit-Position: refs/heads/master@{#35365}
      
      TBR=jochen@chromium.org,bmeurer@chromium.org,yangguo@chromium.org,ahaas@chromium.org
      # Skipping CQ checks because original CL landed less than 1 days ago.
      NOPRESUBMIT=true
      NOTREECHECKS=true
      NOTRY=true
      
      Review URL: https://codereview.chromium.org/1867383002
      
      Cr-Commit-Position: refs/heads/master@{#35366}
      4c4fdc2d
    • jfb's avatar
      Fix printf formats · 6ebf9fbb
      jfb authored
      The usage of __attribute__((format(x, y)) was either wrong or missing from multiple functions, leading to erroneous formats. This CL:
      
       - Imports PRINTF_FORMAT macro from Chrome's src/base/compiler-specific.h.
       - Uses it appropriately.
       - Imports Chrome's base/format_macros.h mainly to fix size_t formats (further cleanup could be done).
       - Fixes a bunch of incorrect formats.
      
      R= jochen@chromium.org, bmeurer@chromium.org, yangguo@chromium.org, ahaas@chromium.org
      
      Review URL: https://codereview.chromium.org/1869433004
      
      Cr-Commit-Position: refs/heads/master@{#35365}
      6ebf9fbb