1. 23 Sep, 2016 1 commit
    • jacob.bramley's avatar
      [arm] Clean up use of IsSupported and IsEnabled. · 73518a90
      jacob.bramley authored
      CpuFeatures::IsSupported(feature) indicates that the feature is
      available on the target. AssemblerBase::IsEnabled(feature) indicates
      that we've checked for support (using CpuFeatureScope). The main benefit
      is that we can test on (for example) ARMv8, but have some assurance that
      we won't generate ARMv8 instructions on ARMv7 targets.
      
      This patch simply cleans up the usage, which had become inconsistent.
      The instruction emission functions now check not only that their
      dependent features are supported, but also that we've verified that
      using CpuFeatureScope.
      
      BUG=
      
      Review-Url: https://codereview.chromium.org/2360243002
      Cr-Commit-Position: refs/heads/master@{#39676}
      73518a90
  2. 27 Jul, 2016 1 commit
  3. 25 Jul, 2016 1 commit
  4. 17 Jun, 2016 1 commit
    • bmeurer's avatar
      [builtins] Introduce proper Float64Exp operator. · d5f2ac5e
      bmeurer authored
      Import base::ieee754::exp() from FreeBSD msun and introduce a Float64Exp
      TurboFan operator based on that, similar to what we do for Float64Log.
      Rewrite Math.exp() as TurboFan builtin and use that operator to also
      inline Math.exp() into optimized TurboFan functions.
      
      CQ_INCLUDE_TRYBOTS=tryserver.chromium.linux:linux_chromium_rel_ng;tryserver.blink:linux_blink_rel
      BUG=v8:3266,v8:3468,v8:3493,v8:5086,v8:5108,chromium:620786
      R=mvstanton@chromium.org
      
      Committed: https://crrev.com/93e26314afc9da9b5b8bd998688262444ed73260
      Review-Url: https://codereview.chromium.org/2077533002
      Cr-Original-Commit-Position: refs/heads/master@{#37037}
      Cr-Commit-Position: refs/heads/master@{#37047}
      d5f2ac5e
  5. 16 Jun, 2016 2 commits
  6. 26 Apr, 2016 1 commit
  7. 16 Mar, 2016 2 commits
  8. 08 Mar, 2016 1 commit
    • danno's avatar
      [runtime] Unify and simplify how frames are marked · 9dcd0857
      danno authored
      Before this CL, various code stubs used different techniques
      for marking their frames to enable stack-crawling and other
      access to data in the frame. All of them were based on a abuse
      of the "standard" frame representation, e.g. storing the a
      context pointer immediately below the frame's fp, and a
      function pointer after that. Although functional, this approach
      tends to make stubs and builtins do an awkward, unnecessary
      dance to appear like standard frames, even if they have
      nothing to do with JavaScript execution.
      
      This CL attempts to improve this by:
      
      * Ensuring that there are only two fundamentally different
        types of frames, a "standard" frame and a "typed" frame.
        Standard frames, as before, contain both a context and
        function pointer. Typed frames contain only a minimum
        of a smi marker in the position immediately below the fp
        where the context is in standard frames.
      * Only interpreted, full codegen, and optimized Crankshaft and
        TurboFan JavaScript frames use the "standard" format. All
        other frames use the type frame format with an explicit
        marker.
      * Typed frames can contain one or more values below the
        type marker. There is new magic macro machinery in
        frames.h that simplifies defining the offsets of these fields
        in typed frames.
      * A new flag in the CallDescriptor enables specifying whether
        a frame is a standard frame or a typed frame. Secondary
        register location spilling is now only enabled for standard
        frames.
      * A zillion places in the code have been updated to deal with
        the fact that most code stubs and internal frames use the
        typed frame format. This includes changes in the
        deoptimizer, debugger, and liveedit.
      * StandardFrameConstants::kMarkerOffset is deprecated,
        (CommonFrameConstants::kContextOrFrameTypeOffset
        and StandardFrameConstants::kFrameOffset are now used
        in its stead).
      
      LOG=N
      
      Review URL: https://codereview.chromium.org/1696043002
      
      Cr-Commit-Position: refs/heads/master@{#34571}
      9dcd0857
  9. 01 Feb, 2016 1 commit
    • mbrandy's avatar
      Detect cache line size on Linux for PPC hosts. · c3ff68b6
      mbrandy authored
      In the interest of generalization, this change:
      - Consolidates cache line size detection for all interested
        architectures under base::CPU (currently leveraged by only
        PPC and ARM64).
      - Differentiates between instruction vs data cache line sizes.
      
      R=rmcilroy@chromium.org, jochen@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com
      BUG=
      
      Review URL: https://codereview.chromium.org/1643363002
      
      Cr-Commit-Position: refs/heads/master@{#33642}
      c3ff68b6
  10. 27 Nov, 2015 1 commit
  11. 26 Nov, 2015 1 commit
  12. 25 Nov, 2015 3 commits
  13. 24 Nov, 2015 1 commit
  14. 11 Sep, 2015 1 commit
  15. 03 Sep, 2015 1 commit
  16. 17 Aug, 2015 1 commit
  17. 13 Jul, 2015 1 commit
  18. 01 Jun, 2015 1 commit
  19. 10 Nov, 2014 1 commit
  20. 09 Oct, 2014 1 commit
  21. 10 Sep, 2014 1 commit
  22. 06 Aug, 2014 1 commit
  23. 04 Aug, 2014 1 commit
  24. 14 Jul, 2014 1 commit
  25. 30 Jun, 2014 1 commit
  26. 20 Jun, 2014 1 commit
  27. 03 Jun, 2014 1 commit
  28. 27 May, 2014 2 commits
  29. 26 May, 2014 2 commits
  30. 06 May, 2014 1 commit
  31. 02 May, 2014 1 commit
  32. 30 Apr, 2014 2 commits
  33. 29 Apr, 2014 1 commit