1. 27 Nov, 2015 1 commit
  2. 30 Sep, 2015 1 commit
  3. 15 May, 2015 1 commit
  4. 19 Mar, 2015 1 commit
  5. 11 Sep, 2014 1 commit
  6. 09 Sep, 2014 1 commit
    • Jacob.Bramley@arm.com's avatar
      Reland r23732: ARM64: Fix and improve --trace-sim register trace. · 3dbb3c39
      Jacob.Bramley@arm.com authored
      - Use standard names (except that our GREY is the standard BLACK).
      - Make non-bold colours explicit, otherwise the boldness can carry over
        into subsequent colour declarations.
      - I've moved some colours around to make them consistent. Register value
        updates (which are very common) now stand out less than they did,
        making the less-common (and arguably more important) debug
        announcements appear brighter.
        - FP registers and values are now magenta.
        - Integer registers and values are now cyan.
        - Memory accesses are now blue.
      - LOG_WRITE prints the source register for stores.
      - Loads are logged with a format similar to that used for stores.
        Specifically, the memory address is printed alongside the new register
        value.
      - Updates to D registers print the raw bits as well as the double value.
        Updates to S registers print the raw bits as well as the float value.
        (Previously, we printed both double and float interpretations of the
        bits, which was a bit cluttered.)
      
      BUG=
      R=svenpanne@chromium.org
      
      Review URL: https://codereview.chromium.org/551823004
      
      git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@23802 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
      3dbb3c39
  7. 08 Sep, 2014 1 commit
  8. 05 Sep, 2014 1 commit
    • Jacob.Bramley@arm.com's avatar
      ARM64: Fix and improve --trace-sim register trace. · d0054c75
      Jacob.Bramley@arm.com authored
      - Use standard names (except that our GREY is the standard BLACK).
      - Make non-bold colours explicit, otherwise the boldness can carry over
        into subsequent colour declarations.
      - I've moved some colours around to make them consistent. Register value
        updates (which are very common) now stand out less than they did,
        making the less-common (and arguably more important) debug
        announcements appear brighter.
        - FP registers and values are now magenta.
        - Integer registers and values are now cyan.
        - Memory accesses are now blue.
      - LOG_WRITE prints the source register for stores.
      - Loads are logged with a format similar to that used for stores.
        Specifically, the memory address is printed alongside the new register
        value.
      - Updates to D registers print the raw bits as well as the double value.
        Updates to S registers print the raw bits as well as the float value.
        (Previously, we printed both double and float interpretations of the
        bits, which was a bit cluttered.)
      
      BUG=
      R=ulan@chromium.org
      
      Review URL: https://codereview.chromium.org/548473002
      
      git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@23732 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
      d0054c75
  9. 04 Aug, 2014 1 commit
  10. 20 Jun, 2014 1 commit
  11. 09 Jun, 2014 1 commit
  12. 03 Jun, 2014 1 commit
  13. 12 May, 2014 1 commit
    • Jacob.Bramley@arm.com's avatar
      ARM64: Fix and improve MacroAssembler::Printf. · e876dab9
      Jacob.Bramley@arm.com authored
        - W-sized values passed to Printf are now handled correctly by the
          simulator. In AAPCS64, int32_t and int64_t are passed in the same
          way, so this didn't affect non-simulator builds.
        - Since Printf now records the type and size of each argument, it is
          possible to mix argument types.
        - It is now possible to print the stack pointer. There is only one
          remaining restriction: The `csp` register cannot be printed unless
          it is the current stack pointer. This is because it is modified by
          BumpSystemStackPointer when the caller-saved registers are
          preserved.
      
      BUG=
      R=rmcilroy@chromium.org
      
      Review URL: https://codereview.chromium.org/268353005
      
      git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@21272 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
      e876dab9
  14. 29 Apr, 2014 1 commit
  15. 14 Apr, 2014 1 commit
  16. 07 Apr, 2014 1 commit
  17. 21 Mar, 2014 1 commit
  18. 18 Mar, 2014 1 commit
  19. 14 Mar, 2014 2 commits
    • svenpanne@chromium.org's avatar
      Speed up A64 simulator by removing useless memcpy. · c4504388
      svenpanne@chromium.org authored
      The addresses involved should always be aligned, so we can simply use
      a cast, just like the ARM simulator. Even if the alignment assumption
      did not hold and the platform we are running on couldn't handle
      unaligned access, some #ifdefs would be much more preferable. The
      affected member functions were the top 2 in a profile (18% and 15%),
      so basically every hack is allowed here to speed things up. :-)
      
      Removed some dead code for literals on the way. If we need to
      resurrect it, we should do it without double(!) memcpys.
      
      Generally, I still don't understand why we need the Instr/Instruction
      distinction or simply wrap Instr within Instruction, this seems to
      be much simpler and cleaner, but this would involve heavier changes.
      
      The overall speedup of this CL is roughly 37%, see the numbers below
      for a reduced Octane suite and the check targets:
      
      ------------------------------------------------------------
      With memcpy:
      ------------------------------------------------------------
      
      make -j32 a64.release.quickcheck => 03:29
      make -j32 a64.release.check      => 11:30
      Reduced Octane suite             => 05:16
      Richards: 35.1
      DeltaBlue: 64.1
      RayTrace: 130
      Splay: 66.1
      SplayLatency: 619
      NavierStokes: 58.7
      PdfJS: 89.6
      Mandreel: 58.5
      MandreelLatency: 242
      CodeLoad: 5103
      Box2D: 124
      ----
      Score (version 9): 144
      
      ------------------------------------------------------------
      With casts:
      ------------------------------------------------------------
      make -j32 a64.release.quickcheck => 02:14
      make -j32 a64.release.check      => 07:21
      Reduced Octane suite             => 03:21
      Richards: 53.3
      DeltaBlue: 103
      RayTrace: 205
      Splay: 95.9
      SplayLatency: 859
      NavierStokes: 103
      PdfJS: 136
      Mandreel: 94.8
      MandreelLatency: 386
      CodeLoad: 6493
      Box2D: 179
      ----
      Score (version 9): 219
      
      R=ulan@chromium.org
      
      Review URL: https://codereview.chromium.org/195873009
      
      git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@19929 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
      c4504388
    • jacob.bramley@arm.com's avatar
      A64: Fix a few simulation inaccuracies. · cf43195d
      jacob.bramley@arm.com authored
        - Return the correct NaN when an invalid operation generates a NaN.
        - When one or more operands are NaN, handle them as the processor
          would, prioritising signalling NaNs and making them quiet.
        - Fix fmadd and related instructions:
           - Fnmadd is fma(-n, m, -a), not -fma(n, m, a).
           - Some common libc implementations incorrectly implement fma for
             zero results, so work around these cases.
        - Replace some unreliable tests.
      
      This patch also adds support for Default-NaN mode, since once all the
      other work was done, it only required a couple of lines of code.
      Default-NaN mode was used for an optimisation in ARM, and it should now
      be possible to apply the same optimisation to A64.
      
      BUG=
      R=jochen@chromium.org
      
      Review URL: https://codereview.chromium.org/199083005
      
      git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@19927 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
      cf43195d
  20. 18 Feb, 2014 1 commit
    • alexandre.rames@arm.com's avatar
      A64: Let the MacroAssembler resolve branches to distant targets. · 62116e2c
      alexandre.rames@arm.com authored
      Code generation would fail when assembling a branch to a label that is bound
      outside the immediate range of the instruction. A64 is sensitive to this, as the
      various branching instructions have different ranges, going down to +-32KB for
      TBZ/TBNZ.  The MacroAssembler is augmented to handle branches to targets that
      may exceed the immediate range of instructions.
      
      When branching backward to a label exceeding the instruction range, the
      MacroAssembler can simply tweak the generated code to use an unconditional
      branch with a longer range. For example instead of
          B(cond, &label);
      the MacroAssembler can generate:
          b(InvertCondition(cond), &done);
          b(&label);
          bind(&done);
      
      Since the target is not known when the branch is emitted, forward branches uses
      a different mechanism. The MacroAssembler keeps track of forward branches to
      unbound labels. When the code generation approaches the end of the range of a
      branch, a veneer is generated for the branch.
      
      BUG=v8:3148
      LOG=Y
      R=ulan@chromium.org
      
      Review URL: https://codereview.chromium.org/169893002
      
      git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@19444 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
      62116e2c
  21. 12 Feb, 2014 1 commit