Skip to content

V
V8
Switch branch/tag
  1. 08 Nov, 2016 2 commits
  3. 27 Oct, 2016 1 commit
    • ishell's avatar
      [ic] Remove unnecessary access rights checks from the IC handlers. · 8ba4af44
      ishell authored 
      The reasons are:
1) Type feedback vectors are not shared between different native contexts and
   therefore the IC handler created for one native context will not be reused
   in other native context.
2) Access rights revocation is not supported at all, therefore given (1) once
   we pass the access check we don't have to check access rights again.

BUG=v8:5561

Review-Url: https://codereview.chromium.org/2455953002
Cr-Commit-Position: refs/heads/master@{#40627}
      8ba4af44
  5. 26 Oct, 2016 1 commit
    • bmeurer's avatar
      [compiler] Properly validate stable map assumption for globals. · 2bd7464e
      bmeurer authored 
      For global object property cells, we did not check that the map on the
previous object is still the same for which we actually optimized. So
the optimized code was not in sync with the actual state of the property
cell. When loading from such a global object property cell, Crankshaft
optimizes away any map checks (based on the stable map assumption),
leading to arbitrary memory access in the worst case.

TurboFan has the same bug for stores, but is safe on loads because we
do appropriate map checks there. However mixing TurboFan and Crankshaft
still exposes the bug.

R=yangguo@chromium.org
BUG=chromium:659475

Review-Url: https://codereview.chromium.org/2444233004
Cr-Commit-Position: refs/heads/master@{#40592}
      2bd7464e
  7. 20 Oct, 2016 1 commit
  9. 17 Oct, 2016 1 commit
  11. 23 Sep, 2016 1 commit
  13. 20 Sep, 2016 1 commit
  15. 31 Aug, 2016 1 commit
    • adamk's avatar
      Remove CONST_LEGACY VariableMode · 7516fe1e
      adamk authored 
      The only remaining use of this VariableMode is for the names of sloppy
named function expressions. This patch instead uses CONST for such
bindings (just as we do in strict mode) and instead marks those
Variables specially. During code generation a new helper method,
Variable::throw_on_const_assignment(), is called to decide whether
to throw or silently ignore the assignment.

Review-Url: https://codereview.chromium.org/2233673003
Cr-Commit-Position: refs/heads/master@{#39052}
      7516fe1e
  17. 25 Aug, 2016 3 commits
    • jarin's avatar
      Reland of [turbofan] Insert dummy values when changing from None type. · 2a97b1bc
      jarin authored 
      This reverts commit a55fdb1e, relands
https://codereview.chromium.org/2266823002/.

BUG=chromium:638132

Review-Url: https://codereview.chromium.org/2277283002
Cr-Commit-Position: refs/heads/master@{#38917}
      2a97b1bc
    • bmeurer's avatar
      Revert of [turbofan] Insert dummy values when changing from None type.... · a55fdb1e
      bmeurer authored 
      Revert of [turbofan] Insert dummy values when changing from None type. (patchset #5 id:80001 of https://codereview.chromium.org/2266823002/ )

Reason for revert:
Octane/Mandreel aborts with an exception now:

TypeError: __FUNCTION_TABLE__[(r2 >> 2)] is not a function

Original issue's description:
> [turbofan] Insert dummy values when changing from None type.
>
> Currently we choose the MachineRepresentation::kNone representation for
> values of Type::None, and when converting values from the kNone representation
> we use "impossible" conversions that will crash at runtime. This
> assumes that the impossible conversions should never be hit (the only
> way to produce the impossible values is to perform an always-failing
> runtime check on a value, such as Smi-checking a string). Note that
> this assumes that the runtime check is executed before the impossible
> convesrion.
>
> Introducing BitwiseOr type feedback broke this in two ways:
>
> - we always pick Word32 representation for bitwise-or, so the
>   impossible conversion does not trigger (it only triggers with
>   None representation), and we could end up with unsupported
>   conversions from Word32.
>
> - even if we inserted impossible conversions, they are pure conversions.
>   Since untagging, bitwise-or operations are also pure, we could hoist
>   all these before the smi check of the inputs and we could hit the
>   impossible conversions before we get to the smi check.
>
> This CL addresses this by just providing dummy values for conversions
> from the Type::None type. It also removes the impossible-to-* conversions.
>
> BUG=chromium:638132
>
> Committed: https://crrev.com/c83b21ab755f1420b6da85b3ff43d7e96ead9bbe
> Cr-Commit-Position: refs/heads/master@{#38883}

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

Review-Url: https://codereview.chromium.org/2280613002
Cr-Commit-Position: refs/heads/master@{#38893}
      a55fdb1e
    • jarin's avatar
      [turbofan] Insert dummy values when changing from None type. · c83b21ab
      jarin authored 
      Currently we choose the MachineRepresentation::kNone representation for
values of Type::None, and when converting values from the kNone representation
we use "impossible" conversions that will crash at runtime. This
assumes that the impossible conversions should never be hit (the only
way to produce the impossible values is to perform an always-failing
runtime check on a value, such as Smi-checking a string). Note that
this assumes that the runtime check is executed before the impossible
convesrion.

Introducing BitwiseOr type feedback broke this in two ways:

- we always pick Word32 representation for bitwise-or, so the
  impossible conversion does not trigger (it only triggers with
  None representation), and we could end up with unsupported
  conversions from Word32.

- even if we inserted impossible conversions, they are pure conversions.
  Since untagging, bitwise-or operations are also pure, we could hoist
  all these before the smi check of the inputs and we could hit the
  impossible conversions before we get to the smi check.

This CL addresses this by just providing dummy values for conversions
from the Type::None type. It also removes the impossible-to-* conversions.

BUG=chromium:638132

Review-Url: https://codereview.chromium.org/2266823002
Cr-Commit-Position: refs/heads/master@{#38883}
      c83b21ab
  19. 05 Aug, 2016 1 commit
  21. 25 Jul, 2016 1 commit
  23. 18 Jul, 2016 1 commit
    • neis's avatar
      [modules] AST and parser rework. · 0e000a87
      neis authored 
      Highlights:
- Record all imports and exports in the ModuleDescriptor.
- Remove ImportDeclaration; instead, introduce a new variable kind for imports.
- Set name on default exported anonymous functions.

Still to do: declaration of namespace imports.

BUG=v8:1569

Review-Url: https://codereview.chromium.org/2108193003
Cr-Commit-Position: refs/heads/master@{#37815}
      0e000a87
  25. 05 Jul, 2016 1 commit
  27. 28 Jun, 2016 1 commit
  29. 13 Jun, 2016 1 commit
  31. 18 May, 2016 1 commit
  33. 17 May, 2016 5 commits
  35. 16 May, 2016 1 commit
  37. 13 May, 2016 1 commit
  39. 11 May, 2016 1 commit
    • rmcilroy's avatar
      [Interpreter] Fix incorrect frame walking in arguments create stubs · 40f34541
      rmcilroy authored 
      The previous approach taken by FastNew[Sloppy,Strict,Rest]ArgumentsStub
looked at the function slot in order to skip stub frames
and find the JS frame. However, stub frames do not have a
function slot (in fact their fixed frame ends one slot
before the JS frame's function slot). Therefore, if this
location in the stub frame happens to have the function
object the create arguments stubs won't skip this frame
correctly.

Replace this approach with one where the stub is
specialized to either skip a frame if required (since
there will only ever be one extra frame on Ignition
the loop approach isn't necessary).

BUG=v8:4928
LOG=N
CQ_INCLUDE_TRYBOTS=tryserver.v8:v8_linux_nosnap_dbg

Review-Url: https://codereview.chromium.org/1949023003
Cr-Commit-Position: refs/heads/master@{#36181}
      40f34541
  41. 10 May, 2016 1 commit
  43. 28 Apr, 2016 1 commit
  45. 11 Apr, 2016 1 commit
    • mstarzinger's avatar
      [compiler] Make OptimizedCompileJob agnostic from backend. · dea67cf0
      mstarzinger authored 
      This refactors the OptimizedCompileJob class to be agnostic from the
actual underlying compiler. Instead it represents a base class for all
compilation jobs. The implementation is provided by the backend by just
overriding the phase methods.

Also note that this contains the semantics change of not falling back to
Crankshaft when TurboFan optimization fails. This fallback is no longer
needed and will not be supported going forward.

R=bmeurer@chromium.org

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

Cr-Commit-Position: refs/heads/master@{#35377}
      dea67cf0
  47. 06 Apr, 2016 1 commit
    • bmeurer's avatar
      [generators] Decouple generator resume from fullcodegen. · 974721c6
      bmeurer authored 
      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.

R=mstarzinger@chromium.org, neis@chromium.org
TBR=rossberg@chromium.org
BUG=chromium:513471
LOG=n

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

Cr-Commit-Position: refs/heads/master@{#35283}
      974721c6
  49. 22 Mar, 2016 2 commits
    • adamk's avatar
      Remove support for legacy const, part 1 · ed18aa65
      adamk authored 
      Now that ES2015 const has shipped, in Chrome 49, legacy const declarations
are no more. This lets us remove a bunch of code from many parts of the
codebase.

In this patch, I remove parser support for generating legacy const variables
from const declarations. This also removes the special "illegal declaration"
bit from Scope, which has ripples into all compiler backends.

Also gone are any tests which relied on legacy const declarations.

Note that we do still generate a Variable in mode CONST_LEGACY in one case:
function name bindings in sloppy mode. The likely fix there is to add a new
Variable::Kind for this case and handle it appropriately for stores in each
backend, but I leave that for a later patch to make this one completely
subtractive.

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

Cr-Commit-Position: refs/heads/master@{#35002}
      ed18aa65
    • epertoso's avatar
      [Interpreter] TurboFan implementation of intrinsics. · d158bf14
      epertoso authored 
      Introduces a bytecode whose handler executes the equivalent of %_IsArray and %_IsJSReceiver without a runtime call.

BUG=v8:4822
LOG=y

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

Cr-Commit-Position: refs/heads/master@{#34983}
      d158bf14
  51. 21 Mar, 2016 2 commits
    • oth's avatar
      [interpreter] Add support for scalable operands. · 48d082af
      oth authored 
      This change introduces wide prefix bytecodes to support wide (16-bit)
and extra-wide (32-bit) operands. It retires the previous
wide-bytecodes and reduces the number of operand types.

Operands are now either scalable or fixed size. Scalable operands
increase in width when a bytecode is prefixed with wide or extra-wide.

The bytecode handler table is extended to 256*3 entries. The
first 256 entries are used for bytecodes with 8-bit operands,
the second 256 entries are used for bytecodes with operands that
scale to 16-bits, and the third group of 256 entries are used for
bytecodes with operands that scale to 32-bits.

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

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

Cr-Commit-Position: refs/heads/master@{#34955}
      48d082af
    • bmeurer's avatar
      [stubs] Split ToNumberStub into reusable subparts. · b7aa4c3a
      bmeurer authored 
      Split ToNumberStub into the entry ToNumberStub, and two new stubs,
StringToNumberStub and NonNumberToNumberStub, which can be used when we
already know something about the input (i.e. in various branches of the
code stubs, or in TurboFan graphs).

Also introduce an appropriate StringToNumber simplified operator for
TurboFan, that is pure and is lowered to an invocation of the newly
added StringToNumberStub.

R=jarin@chromium.org

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

Cr-Commit-Position: refs/heads/master@{#34922}
      b7aa4c3a
  53. 16 Mar, 2016 1 commit
  55. 10 Mar, 2016 1 commit
    • mstarzinger's avatar
      [compiler] Sidestep optimizing of generator resumers. · 85517653
      mstarzinger authored 
      This ensures our optimizing compilers as well as the interpreter are
never tasked with compiling the generator-resuming builtin methods. The
corresponding intrinsics for those methods are not supported and it is
not possible to provide a C++ reference implementation for them. We do
this by assigning builtin function ids to them that we can recognize
during the compiler dispatch.

Note that this also affects the interpreter, because methods having a
builtin function id assigned are not interpreted ({function_data} field
is overlapping). If this ever changes we can still do an early check in
the compiler dispatch (similar to the optimizing compilers) easily.

This applies to the following methods:
- Generator.prototype.next (calls Runtime_GeneratorNext).
- Generator.prototype.return (calls Runtime_GeneratorReturn).
- Generator.prototype.throw (calls Runtime_GeneratorThrow).

R=neis@chromium.org
BUG=v8:4681
LOG=n

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

Cr-Commit-Position: refs/heads/master@{#34675}
      85517653
  57. 04 Mar, 2016 1 commit
    • mvstanton's avatar
      Allow Crankshaft to tolerate certain do-expressions · 67838546
      mvstanton authored 
      Crankshaft can't track operand/environment changes between arbitrary statements.
We need that to fully support do-expressions. Instead, a subset is supported
by bailing out on break statements, continue statements, and if we've made an
OSR entry within a do-expression.

This partial support is a good idea because do-expressions are a useful tool
for desugaring during parsing.

BUG=
R=mstarzinger@chromium.org

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

Cr-Commit-Position: refs/heads/master@{#34491}
      67838546
  59. 01 Mar, 2016 1 commit
  61. 25 Feb, 2016 1 commit