Skip to content

V
V8
Switch branch/tag
  1. 06 Sep, 2017 1 commit
    • Clemens Hammacher's avatar
      [assembler] Make Register et al. real classes · 9e995e12
      Clemens Hammacher authored 
      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=mstarzinger@chromium.org

Change-Id: I5ccfa4050daf4e146a557970e9d37fd3d2788d4a
Reviewed-on: https://chromium-review.googlesource.com/650927Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
Reviewed-by: 's avatarIgor Sheludko <ishell@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47847}
      9e995e12
  3. 22 Aug, 2017 3 commits
  5. 11 Aug, 2017 1 commit
  7. 04 Aug, 2017 1 commit
  9. 03 Aug, 2017 2 commits
  11. 07 Jul, 2017 1 commit
  13. 06 Jul, 2017 1 commit
  15. 26 Jun, 2017 1 commit
  17. 23 Jun, 2017 1 commit
  19. 04 May, 2017 1 commit
  21. 24 Apr, 2017 1 commit
  23. 19 Apr, 2017 1 commit
  25. 13 Apr, 2017 1 commit
  27. 22 Mar, 2017 1 commit
  29. 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
  31. 28 Feb, 2017 1 commit
  33. 26 Jan, 2017 1 commit
    • mstarzinger's avatar
      [deoptimizer] Preserve double bit patterns correctly. · 7376e12e
      mstarzinger authored 
      This makes sure that the deoptimizer preserves the exact bit pattern of
floating-point values (both 32-bit and 64-bit) up to the point where a
potential {HeapNumber} is allocated. It in turn allows us to correctly
recognize the {hole_nan_value} when stored into a {FixedDouleArray}.

R=jarin@chromium.org
TEST=mjsunit/regress/regress-crbug-684208
BUG=chromium:684208

Review-Url: https://codereview.chromium.org/2652303002
Cr-Commit-Position: refs/heads/master@{#42679}
      7376e12e
  35. 11 Nov, 2016 1 commit
  37. 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
  39. 27 Jun, 2016 1 commit
  41. 01 Jun, 2016 1 commit
    • jacob.bramley's avatar
      [arm] Fix test failures on old architectures. · 886b259e
      jacob.bramley authored 
      This mostly affects ARMv6, but also fixes some failures on ARMv7 when
hardware integer division is not available.

- Fix a case where a CodePatcher accumulates literal pool entries, but
  does not actually emit them.
- Don't treat division as safe if we can't use the hardware instruction.
  Our fallback implementation returns the wrong result if the divisor is
  zero.
- Support deoptimization tables bigger than 8 bits. (kMaxNumberOfEntries
  requires a 16-bit table index.)
- Correct a TurboFan instruction encoding to encode the Operand2 mode.

BUG=

Review-Url: https://codereview.chromium.org/2021343002
Cr-Commit-Position: refs/heads/master@{#36636}
      886b259e
  43. 09 Mar, 2016 2 commits
  45. 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
  47. 03 Mar, 2016 1 commit
  49. 15 Feb, 2016 1 commit
  51. 11 Feb, 2016 1 commit
  53. 27 Nov, 2015 1 commit
  55. 22 Oct, 2015 1 commit
  57. 02 Oct, 2015 3 commits
    • danno's avatar
      Re-reland: Remove register index/code indirection · 5cf1c0bc
      danno authored 
      Previous to this patch, both the lithium and TurboFan register
allocators tracked allocated registers by "indices", rather than
the register codes used elsewhere in the runtime. This patch
ensures that codes are used everywhere, and in the process cleans
up a bunch of redundant code and adds more structure to how the
set of allocatable registers is defined.

Some highlights of changes:

* TurboFan's RegisterConfiguration class moved to V8's top level
  so that it can be shared with Crankshaft.
* Various "ToAllocationIndex" and related methods removed.
* Code that can be easily shared between Register classes on
  different platforms is now shared.
* The list of allocatable registers on each platform is declared
  as a list rather than implicitly via the register index <->
  code mapping.

Committed: https://crrev.com/80bc6f6e11f79524e3f1ad05579583adfd5f18b2
Cr-Commit-Position: refs/heads/master@{#30913}

Committed: https://crrev.com/7b7a8205d9a00c678fb7a6e032a55fecbc1509cf
Cr-Commit-Position: refs/heads/master@{#31075}

Review URL: https://codereview.chromium.org/1287383003

Cr-Commit-Position: refs/heads/master@{#31087}
      5cf1c0bc
    • danno's avatar
      Revert of Reland: Remove register index/code indirection (patchset #20... · 00e07b00
      danno authored 
      Revert of Reland: Remove register index/code indirection (patchset #20 id:380001 of https://codereview.chromium.org/1287383003/ )

Reason for revert:
Failures on MIPS

Original issue's description:
> Remove register index/code indirection
>
> Previous to this patch, both the lithium and TurboFan register
> allocators tracked allocated registers by "indices", rather than
> the register codes used elsewhere in the runtime. This patch
> ensures that codes are used everywhere, and in the process cleans
> up a bunch of redundant code and adds more structure to how the
> set of allocatable registers is defined.
>
> Some highlights of changes:
>
> * TurboFan's RegisterConfiguration class moved to V8's top level
>   so that it can be shared with Crankshaft.
> * Various "ToAllocationIndex" and related methods removed.
> * Code that can be easily shared between Register classes on
>   different platforms is now shared.
> * The list of allocatable registers on each platform is declared
>   as a list rather than implicitly via the register index <->
>   code mapping.
>
> Committed: https://crrev.com/80bc6f6e11f79524e3f1ad05579583adfd5f18b2
> Cr-Commit-Position: refs/heads/master@{#30913}
>
> Committed: https://crrev.com/7b7a8205d9a00c678fb7a6e032a55fecbc1509cf
> Cr-Commit-Position: refs/heads/master@{#31075}

TBR=akos.palfi@imgtec.com,bmeurer@chromium.org,jarin@chromium.org,paul.lind@imgtec.com,titzer@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true

Review URL: https://codereview.chromium.org/1380863004

Cr-Commit-Position: refs/heads/master@{#31083}
      00e07b00
    • danno's avatar
      Remove register index/code indirection · 7b7a8205
      danno authored 
      Previous to this patch, both the lithium and TurboFan register
allocators tracked allocated registers by "indices", rather than
the register codes used elsewhere in the runtime. This patch
ensures that codes are used everywhere, and in the process cleans
up a bunch of redundant code and adds more structure to how the
set of allocatable registers is defined.

Some highlights of changes:

* TurboFan's RegisterConfiguration class moved to V8's top level
  so that it can be shared with Crankshaft.
* Various "ToAllocationIndex" and related methods removed.
* Code that can be easily shared between Register classes on
  different platforms is now shared.
* The list of allocatable registers on each platform is declared
  as a list rather than implicitly via the register index <->
  code mapping.

Committed: https://crrev.com/80bc6f6e11f79524e3f1ad05579583adfd5f18b2
Cr-Commit-Position: refs/heads/master@{#30913}

Review URL: https://codereview.chromium.org/1287383003

Cr-Commit-Position: refs/heads/master@{#31075}
      7b7a8205
  59. 24 Sep, 2015 2 commits
    • danno's avatar
      Revert of Remove register index/code indirection (patchset #17 id:320001 of... · 3ac27431
      danno authored 
      Revert of Remove register index/code indirection (patchset #17 id:320001 of https://codereview.chromium.org/1287383003/ )

Reason for revert:
Failures on greedy RegAlloc, Fuzzer

Original issue's description:
> Remove register index/code indirection
>
> Previous to this patch, both the lithium and TurboFan register
> allocators tracked allocated registers by "indices", rather than
> the register codes used elsewhere in the runtime. This patch
> ensures that codes are used everywhere, and in the process cleans
> up a bunch of redundant code and adds more structure to how the
> set of allocatable registers is defined.
>
> Some highlights of changes:
>
> * TurboFan's RegisterConfiguration class moved to V8's top level
>   so that it can be shared with Crankshaft.
> * Various "ToAllocationIndex" and related methods removed.
> * Code that can be easily shared between Register classes on
>   different platforms is now shared.
> * The list of allocatable registers on each platform is declared
>   as a list rather than implicitly via the register index <->
>   code mapping.
>
> Committed: https://crrev.com/80bc6f6e11f79524e3f1ad05579583adfd5f18b2
> Cr-Commit-Position: refs/heads/master@{#30913}

TBR=akos.palfi@imgtec.com,bmeurer@chromium.org,jarin@chromium.org,paul.lind@imgtec.com,titzer@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true

Review URL: https://codereview.chromium.org/1365073002

Cr-Commit-Position: refs/heads/master@{#30914}
      3ac27431
    • danno's avatar
      Remove register index/code indirection · 80bc6f6e
      danno authored 
      Previous to this patch, both the lithium and TurboFan register
allocators tracked allocated registers by "indices", rather than
the register codes used elsewhere in the runtime. This patch
ensures that codes are used everywhere, and in the process cleans
up a bunch of redundant code and adds more structure to how the
set of allocatable registers is defined.

Some highlights of changes:

* TurboFan's RegisterConfiguration class moved to V8's top level
  so that it can be shared with Crankshaft.
* Various "ToAllocationIndex" and related methods removed.
* Code that can be easily shared between Register classes on
  different platforms is now shared.
* The list of allocatable registers on each platform is declared
  as a list rather than implicitly via the register index <->
  code mapping.

Review URL: https://codereview.chromium.org/1287383003

Cr-Commit-Position: refs/heads/master@{#30913}
      80bc6f6e
  61. 17 Aug, 2015 1 commit
  63. 24 Jul, 2015 1 commit
  65. 04 Jun, 2015 1 commit
    • mbrandy's avatar
      Add support for Embedded Constant Pools for PPC and Arm · eac7f046
      mbrandy authored 
      Embed constant pools within their corresponding Code
objects.

This removes support for out-of-line constant pools in favor
of the new approach -- the main advantage being that it
eliminates the need to allocate and manage separate constant
pool array objects.

Currently supported on PPC and ARM.  Enabled by default on
PPC only.

This yields a 6% improvment in Octane on PPC64.

R=bmeurer@chromium.org, rmcilroy@chromium.org, michael_dawson@ca.ibm.com
BUG=chromium:478811
LOG=Y

Review URL: https://codereview.chromium.org/1162993006

Cr-Commit-Position: refs/heads/master@{#28801}
      eac7f046