Skip to content

V
V8
Switch branch/tag
  1. 03 May, 2016 2 commits
  3. 27 Apr, 2016 1 commit
  5. 26 Apr, 2016 1 commit
  7. 25 Apr, 2016 1 commit
  9. 20 Apr, 2016 3 commits
  11. 19 Apr, 2016 1 commit
  13. 18 Apr, 2016 1 commit
  15. 16 Apr, 2016 2 commits
  17. 13 Apr, 2016 2 commits
  19. 12 Apr, 2016 1 commit
    • binji's avatar
      [Atomics] code stubs for atomic operations · 10b5febe
      binji authored 
      * New atomic code stubs for x64, ia32, arm, arm64
* Add convenience functions JumpIfNotValidSmiValue, JumpIfUintNotValidSmiValue
  to macro-assembler-ia32 (API based on x64 macro assembler)
* Remove runtime implementation of Atomics.load, the code stub should always be
  called instead
* Add new test to mjsunit atomics test; check that Smi values of different
  sizes are supported when possible, else fall back to HeapNumbers

These changes were needed to add another codestub:
* Bump kStubMajorKeyBits from 7 to 8
* Reduce ScriptContextFieldStub::kSlotIndexBits from 13 to 12

BUG=v8:4614
LOG=y

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

Cr-Commit-Position: refs/heads/master@{#35427}
      10b5febe
  21. 06 Apr, 2016 1 commit
    • verwaest's avatar
      Use a dictionary-mode code cache on the map rather than a dual system. · d2eb555e
      verwaest authored 
      The previous code cache system required stubs to be marked with a StubType, causing them to be inserted either into a fixed array or into a dictionary-mode code cache. This could cause names to be in both cases, and lookup would just find the "fast" one first. Given that we clear out the caches on each GC, the memory overhead shouldn't be too bad. Additionally, the dictionary itself should just stay linear for small arrays; that's faster anyway.

This CL additionally deletes some dead IC code.

BUG=

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

Cr-Commit-Position: refs/heads/master@{#35291}
      d2eb555e
  23. 30 Mar, 2016 1 commit
  25. 22 Mar, 2016 1 commit
  27. 21 Mar, 2016 4 commits
  29. 17 Mar, 2016 1 commit
  31. 10 Mar, 2016 1 commit
  33. 09 Mar, 2016 5 commits
    • ahaas's avatar
      [wasm] Int64Lowering of I64ShrU and I64ShrS on ia32. · 240b7db9
      ahaas authored 
      I implemented I64ShrU and I64ShrS the same as I64Shl in https://codereview.chromium.org/1756863002

R=titzer@chromium.org

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

Cr-Commit-Position: refs/heads/master@{#34630}
      240b7db9
    • vogelheim's avatar
      Rework CallApi*Stubs. · 5096492f
      vogelheim authored 
      - Eliminate stubs with a variable number of arguments.
  (That only worked due to their very limited use. These
   stubs' interface descriptors were basically lying
   about their number of args, which will fail when used
   generically.)
- Fix all CallApi*Stubs' interface descriptors to no
  longer lie about their arguments.
- Unify CallApi*Stub, for * in Function, Accessor,
  FunctionWithFixedArgs.
  (Since these are now all doing the same thing.)
- Rename the unified stub (and interface descriptors) to
  *ApiCallback*, since that's really what they're doing.
- Refuse inlining an API callback if its number of
  parameters exceeds the supported number of args.

BUG=

Committed: https://crrev.com/d238b953a474272c0e3ea22ef6a9b63fa9729340
Cr-Commit-Position: refs/heads/master@{#34614}

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

Cr-Commit-Position: refs/heads/master@{#34627}
      5096492f
    • vogelheim's avatar
      Revert of Rework CallApi*Stubs. (patchset #5 id:100001 of... · 52a741d1
      vogelheim authored 
      Revert of Rework CallApi*Stubs. (patchset #5 id:100001 of https://codereview.chromium.org/1748123003/ )

Reason for revert:
Breaks Chromium.

Original issue's description:
> Rework CallApi*Stubs.
>
> - Eliminate stubs with a variable number of arguments.
>   (That only worked due to their very limited use. These
>    stubs' interface descriptors were basically lying
>    about their number of args, which will fail when used
>    generically.)
> - Fix all CallApi*Stubs' interface descriptors to no
>   longer lie about their arguments.
> - Unify CallApi*Stub, for * in Function, Accessor,
>   FunctionWithFixedArgs.
>   (Since these are now all doing the same thing.)
> - Rename the unified stub (and interface descriptors) to
>   *ApiCallback*, since that's really what they're doing.
> - Refuse inlining an API callback if its number of
>   parameters exceeds the supported number of args.
>
> BUG=
>
> Committed: https://crrev.com/d238b953a474272c0e3ea22ef6a9b63fa9729340
> Cr-Commit-Position: refs/heads/master@{#34614}

TBR=danno@chromium.org,jkummerow@chromium.org,mstarzinger@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=

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

Cr-Commit-Position: refs/heads/master@{#34624}
      52a741d1
    • vogelheim's avatar
      Rework CallApi*Stubs. · d238b953
      vogelheim authored 
      - Eliminate stubs with a variable number of arguments.
  (That only worked due to their very limited use. These
   stubs' interface descriptors were basically lying
   about their number of args, which will fail when used
   generically.)
- Fix all CallApi*Stubs' interface descriptors to no
  longer lie about their arguments.
- Unify CallApi*Stub, for * in Function, Accessor,
  FunctionWithFixedArgs.
  (Since these are now all doing the same thing.)
- Rename the unified stub (and interface descriptors) to
  *ApiCallback*, since that's really what they're doing.
- Refuse inlining an API callback if its number of
  parameters exceeds the supported number of args.

BUG=

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

Cr-Commit-Position: refs/heads/master@{#34614}
      d238b953
    • bmeurer's avatar
      [undetectable] Really get comparisons of document.all right now. · 679d9503
      bmeurer authored 
      According to https://www.w3.org/TR/html5/obsolete.html#dom-document-all,
comparisons of document.all to other values such as strings or objects,
are unaffected. In fact document.all only gets special treatment in
comparisons with null or undefined according to HTML. Especially setting
the undetectable doesn't make two distinct JSReceivers equal.

R=jarin@chromium.org

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

Cr-Commit-Position: refs/heads/master@{#34608}
      679d9503
  35. 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
  37. 04 Mar, 2016 1 commit
    • bmeurer's avatar
      [compiler] Introduce code stubs for string relational comparisons. · 5912e0f0
      bmeurer authored 
      Add StringLessThanStub, StringLessThanOrEqualStub, StringGreaterThanStub
and StringGreaterThanOrEqualStub, based on the CodeStubAssembler, and
hook them up with TurboFan (and Ignition). The stubs are currently
essentially comparable with the StringCompareStub, which is now
obsolete. We can later extend these stubs to cover more interesting
cases (i.e. two byte sequential string comparisons, etc.).

R=epertoso@chromium.org

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

Cr-Commit-Position: refs/heads/master@{#34485}
      5912e0f0
  39. 02 Mar, 2016 1 commit
    • bmeurer's avatar
      [compiler] Introduce initial StrictEqualStub. · 4acb492e
      bmeurer authored 
      Initial version of a new StrictEqualStub written as TurboFan code stub,
that implements the full strict equality comparison and is usable for
both TurboFan and Ignition (and soon for the generic CompareIC case
too). The stub is not fully optimized yet, i.e. we still go to the
runtime for string comparisons, but that'll be addressed in a follow-up
CL.

R=yangguo@chromium.org

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

Cr-Commit-Position: refs/heads/master@{#34423}
      4acb492e
  41. 26 Feb, 2016 1 commit
    • bmeurer's avatar
      [turbofan] Don't use the CompareIC in JSGenericLowering. · d00da47b
      bmeurer authored 
      The CompareICStub produces an untagged raw word value, which has to be
translated to true or false manually in the TurboFan code. But for lazy
bailout after the CompareIC, we immediately go back to fullcodegen or
Ignition with the raw value, to a location where both fullcodegen and
Ignition expect a boolean value, which might crash or in the worst case
(depending on the exact computation inside the CompareIC) could lead to
arbitrary memory access.

Short-term fix is to use the proper runtime functions (unified with the
interpreter now) for comparisons. Next task is to provide optimized
versions of these based on the CodeStubAssembler, which can then be used
via code stubs in TurboFan or directly in handlers in the interpreter.

R=mstarzinger@chromium.org
BUG=v8:4788
LOG=n

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

Cr-Commit-Position: refs/heads/master@{#34335}
      d00da47b
  43. 25 Feb, 2016 1 commit
    • bmeurer's avatar
      [runtime] Unify comparison operator runtime entries. · 55b4df73
      bmeurer authored 
      Only use one set of %StrictEquals/%StrictNotEquals and
%Equals/%NotEquals runtime entries for both the interpreter
and the old-style CompareICStub. The long-term plan is to
update the CompareICStub to also return boolean values, and
even allow some more code sharing with the interpreter there.

R=mstarzinger@chromium.org

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

Cr-Commit-Position: refs/heads/master@{#34303}
      55b4df73
  45. 24 Feb, 2016 2 commits
    • mythria's avatar
      Revert of [Interpreter] Implements calls through CallICStub in the... · eb358178
      mythria authored 
      Revert of [Interpreter] Implements calls through CallICStub in the interpreter. (patchset #15 id:270001 of https://codereview.chromium.org/1688283003/ )

Reason for revert:
It is not a good idea to call CallICStub from the builtin. It might be sensitive to the frame structure. Constructing a internal frame might cause problems. It is much better to inline the code  related to the type feedback vector into the builtin.

Original issue's description:
> [Interpreter] Implements calls through CallICStub in the interpreter.
>
> Calls are implemented through CallICStub to collect type feedback. Adds
> a new builtin called InterpreterPushArgsAndCallIC that pushes the
> arguments onto stack and calls CallICStub.
>
> Also adds two new bytecodes CallIC and CallICWide to indicate calls have to
> go through CallICStub.
>
> MIPS port contributed by balazs.kilvady.
>
> BUG=v8:4280, v8:4680
> LOG=N
>
> Committed: https://crrev.com/20362a2214c11a0f2ea5141b6a79e09458939cec
> Cr-Commit-Position: refs/heads/master@{#34244}

TBR=rmcilroy@chromium.org,mvstanton@chromium.org,mstarzinger@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:4280, v8:4680

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

Cr-Commit-Position: refs/heads/master@{#34252}
      eb358178
    • mythria's avatar
      [Interpreter] Implements calls through CallICStub in the interpreter. · 20362a22
      mythria authored 
      Calls are implemented through CallICStub to collect type feedback. Adds
a new builtin called InterpreterPushArgsAndCallIC that pushes the
arguments onto stack and calls CallICStub.

Also adds two new bytecodes CallIC and CallICWide to indicate calls have to
go through CallICStub.

MIPS port contributed by balazs.kilvady.

BUG=v8:4280, v8:4680
LOG=N

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

Cr-Commit-Position: refs/heads/master@{#34244}
      20362a22
  47. 19 Feb, 2016 1 commit
    • bmeurer's avatar
      [stubs] Introduce a dedicated FastNewObjectStub. · ba2077aa
      bmeurer authored 
      Move the already existing fast case for %NewObject into a dedicated
FastNewObjectStub that we can utilize in places where we would otherwise
fallback to %NewObject immediately, which is rather expensive.

Also use FastNewObjectStub as the generic implementation of JSCreate,
which should make constructor inlining based on SharedFunctionInfo (w/o
specializing to a concrete closure) viable soon.

R=jarin@chromium.org

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

Cr-Commit-Position: refs/heads/master@{#34136}
      ba2077aa
  49. 16 Feb, 2016 1 commit
  51. 15 Feb, 2016 2 commits