Commit Graph

871 Commits

Author SHA1 Message Date
adamk
ed18aa65ea Remove support for legacy const, part 1
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}
2016-03-22 17:52:13 +00:00
mstarzinger
31d3c8a074 [compiler] Move PassesFilter onto SharedFunctionInfo.
The JSFunction::PassesFilter predicate is not fine-grained enough to
actually distinguish different closures and hence can be changed into
SharedFunctionInfo::PassesFilter instead. This will allow the compiler
to use is more broadly.

R=jkummerow@chromium.org

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

Cr-Commit-Position: refs/heads/master@{#34981}
2016-03-22 10:02:15 +00:00
mstarzinger
62d2aa45e4 [compiler] Move feedback vector allocation to pipeline.
This moves the call-sites that ensure we have a feedback vector present
before kicking off a compiler into the actual compilation pipeline. The
backends no longer need to worry about the feedback vector.

R=mvstanton@chromium.org

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

Cr-Commit-Position: refs/heads/master@{#34900}
2016-03-18 16:33:55 +00:00
mstarzinger
6691814f58 [compiler] Readability refactor of comilation pipeline.
This is a pure refactoring CL and should not contain any functional
changes to the code. The following has been done:
- Group compiler.cc into sections for each component.
- Surround local helper methods by anonymous namespace.
- Move implementation of Compiler (API class) together.

R=yangguo@chromium.org

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

Cr-Commit-Position: refs/heads/master@{#34891}
2016-03-18 13:57:42 +00:00
mstarzinger
8ba35e73ba [compiler] Remove redundant unoptimized compile trigger.
The trigger point in question is by now obsolete. The optimized compile
job will itself ensure that deoptimization support is present on the
incoming SharedFunctionInfo, this will make sure to produce baseline
code when necessary. The ScopeInfo is also installed at that point in
time.

R=yangguo@chromium.org

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

Cr-Commit-Position: refs/heads/master@{#34887}
2016-03-18 12:09:30 +00:00
mstarzinger
42c8812d15 [compiler] Allocate SharedFunctionInfo before compile.
This changes the compilation pipeline so that SharedFunctionInfo objects
are always allocated before the various compilers are invoked. It is a
preparation towards having that object available during compile time and
hence reducing the dependency on FunctionLiteral and the need to copy a
lot of the information into the CompilationInfo.

Optimizing compilers already assume the SharedFunctionInfo is present
and the baseline compilers have other heap accesses sprinkled throughout
the compilation process. Duplicating statically available information
from the SharedFunctionInfo within the CompilationInfo has no benefit.

R=yangguo@chromium.org

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

Cr-Commit-Position: refs/heads/master@{#34885}
2016-03-18 10:48:12 +00:00
mstarzinger
c5fcc5fc1f [compiler] Remove CompilationInfo::unoptimized_code field.
R=yangguo@chromium.org

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

Cr-Commit-Position: refs/heads/master@{#34881}
2016-03-18 07:57:32 +00:00
rmcilroy
6bdb970512 [Interpreter]: Move builtin-id from function_data to function_identifier.
Functions with builtin ids can be compiled with Ignition, so it is no longer
an option to overlap the bytecode_array field with the builtin id on
the SharedFunctionInfo object. Instead overlap it with the
inferred_name, which is only used for debug and so shouldn't be required
for functions with builtin ids. This result in the inferred_name field
being renamed to function_identifier, and adding typed accessors for
inferred_name and builtin_function_id.

This is required to build the snapshot with --no-lazy.

BUG=v8:4280
LOG=N

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

Cr-Commit-Position: refs/heads/master@{#34867}
2016-03-17 16:37:59 +00:00
yangguo
6e8958fff4 [serializer] ensure that immortal immovable roots are correctly deserialized.
Immortal immovable roots must be allocated on the first page of the space.
If serializing the root list exceeds the first page, immortal immovable root
objects might end up outside of the first page. That could cause missing
write barriers.

We now iterate the root list twice. The first time we only serialize immortal
immovable root objects. The second time we serialize the rest.

R=mstarzinger@chromium.org

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

Cr-Commit-Position: refs/heads/master@{#34859}
2016-03-17 13:16:25 +00:00
adamk
5a202cce6e Remove --harmony-modules flag and let embedder decide when modules are used
Modules already have a separate entrypoint into the engine (at the moment,
this is v8::ScriptCompiler::CompileModule, though that will change to
something like ParseModule). This meant that requiring a commandline flag
simply added an extra complexity burden on embedders. By removing the v8
flag, this lets embedders use their own flagging mechanism (such as d8's
"--module", or Blink's RuntimeEnabledFeatures) to control whether
modules are to be used.

Also remove old modules tests that were being skipped (since they test
very old, pre-ES2015 modules syntax).

R=littledan@chromium.org
BUG=v8:1569, chromium:594639
LOG=y

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

Cr-Commit-Position: refs/heads/master@{#34764}
2016-03-15 00:45:00 +00:00
yangguo
bae3efface [serializer] add options to compile eagerly and pre-age for code cache.
R=vogelheim@chromium.org
BUG=chromium:594551
LOG=N

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

Cr-Commit-Position: refs/heads/master@{#34761}
2016-03-14 18:57:04 +00:00
mstarzinger
5bd307fa72 [compiler] Sidestep the interpreter for generator literals.
This is because compiler.cc is awesome. There are cases where we do not
yet have a SharedFunctionInfo that can tell us whether we are compiling
a generator function, we query the FunctionLiteral instead.

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

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

Cr-Commit-Position: refs/heads/master@{#34677}
2016-03-10 14:35:40 +00:00
mstarzinger
855176533c [compiler] Sidestep optimizing of generator resumers.
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}
2016-03-10 14:07:10 +00:00
mstarzinger
899105c0bc [compiler] Sidestep the interpreter for generator functions.
This ensures the interpreter is not tasked with compiling generator
functions. It currently does not support suspending activations at
yielding points, but we still want to be able to activate it for the
rest of JavaScript in the meantime.

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

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

Cr-Commit-Position: refs/heads/master@{#34672}
2016-03-10 13:21:51 +00:00
rossberg
4614c7caaf [strong] Remove all remainders of strong mode
R=mstarzinger@chromium.org,bmeurer@chromium.org,adamk@chromium.org
BUG=v8:3956
LOG=Y

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

Cr-Commit-Position: refs/heads/master@{#34669}
2016-03-10 12:45:42 +00:00
ssanfilippo
8447072d60 [Interpreter] Log code-creation events for bytecode handlers.
BUG=v8:4280
LOG=N

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

Cr-Commit-Position: refs/heads/master@{#34631}
2016-03-09 16:52:19 +00:00
mstarzinger
46bd989a3a [compiler] Unify naming of methods in compiler API.
This is a pure refactoring and renaming of methods in the compiler API
with the goal to increase readability. Also the compiler API is moved to
the top of the file, as it is the central piece in that file.

R=yangguo@chromium.org

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

Cr-Commit-Position: refs/heads/master@{#34579}
2016-03-08 12:09:10 +00:00
mstarzinger
cabe6844c2 [compiler] Slightly change API to finalize compile jobs.
This changes the compiler API that finalizes a previously queued
optimization job on the main thread, to not deal with code objects
directly. This is in sync with the rest of the API now.

R=yangguo@chromium.org

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

Cr-Commit-Position: refs/heads/master@{#34577}
2016-03-08 10:10:53 +00:00
mstarzinger
2669224274 [compiler] Remove support for concurrent OSR.
R=yangguo@chromium.org

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

Cr-Commit-Position: refs/heads/master@{#34572}
2016-03-08 09:02:44 +00:00
danno
9dcd0857d6 [runtime] Unify and simplify how frames are marked
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}
2016-03-08 08:36:36 +00:00
mstarzinger
1d7da9c639 [compiler] Move JSFunction post-instantiation tasks.
This moves the post-instantiation work performed on newly allocated
JSFunction objects into the Compiler class. The aim is to eventually
have all decisions how to compile functions be centralized within the
compiler pipeline.

R=mvstanton@chromium.org

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

Cr-Commit-Position: refs/heads/master@{#34550}
2016-03-07 16:26:25 +00:00
mstarzinger
970f1ae610 [compiler] Better description of compiler API.
This adds more comments to the V8 compiler API explaining the entry
methods within that API. It also establishes a separate method for OSR
compilation since {Compiler::GetOptimizedCode} is only used for OSR by
now.

R=danno@chromium.org

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

Cr-Commit-Position: refs/heads/master@{#34503}
2016-03-04 16:11:09 +00:00
mstarzinger
d0b67b984e [compiler] Reduce number of entry points into compiler API.
This removes the entry point to the compiler API which allows requesting
lazily compiled full-codegen code. The aim is to eventually allow the
decisions of which baseline compiler should be used (e.g. Ignition or
full-codegen) be centralized within the compiler pipeline.

R=bmeurer@chromium.org

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

Cr-Commit-Position: refs/heads/master@{#34489}
2016-03-04 10:45:40 +00:00
mstarzinger
8377ce9552 [crankshaft] Move CompilationPhase into separate file.
The CompilationPhase helper class is only used in Crankshaft and is not
suitable for use in other compilers. This factors is out into a separate
file and moves it into the "crankshaft" directory.

R=jkummerow@chromium.org

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

Cr-Commit-Position: refs/heads/master@{#34441}
2016-03-02 17:32:03 +00:00
mstarzinger
56eca6d315 [crankshaft] Remove graph builder from optimized compile job.
There is no reason to keep around the HOptimizedGraphBuilder after the
graph has successfully been built. Later phases in OptimizedCompileJob
should not rely on it anymore.

R=jkummerow@chromium.org

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

Cr-Commit-Position: refs/heads/master@{#34440}
2016-03-02 17:27:38 +00:00
jkummerow
4af7757fdf When Crankshaft aborts compilation, use TurboFan next time
When we try to optimize a function with Crankshaft, but compilation
bails out, don't disable optimization for that function entirely,
just disable Crankshaft, so TurboFan will be used for the next attempt.

Thereby this widens the TurboFan intake valve.

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

Cr-Commit-Position: refs/heads/master@{#34396}
2016-03-01 15:14:00 +00:00
yangguo
6f17848caa [serializer] split up src/snapshot/serialize.*
R=rossberg@chromium.org, ulan@chromium.org, vogelheim@chromium.org

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

Cr-Commit-Position: refs/heads/master@{#34395}
2016-03-01 14:44:08 +00:00
rmcilroy
cb29f9cdbc [Interpreter] Add support for cpu profiler logging.
Adds support for cpu profiler logging to the interpreter. Modifies the
the API to be passed AbstractCode objects instead of Code objects, and
adds extra functions to AbstractCode which is required by log.cc and
cpu-profiler.cc.

The main change in sampler.cc is to determine if a stack frame is an
interpreter stack frame, and if so, use the bytecode address as the pc
for that frame. This allows sampling of bytecode functions. This
requires adding support to SafeStackIterator to determine if a frame is
interpreted, which we do by checking the PC against pre-stored addresses
for the start and end of interpreter entry builtins.

Also removes CodeDeleteEvents which are dead code and haven't
been reported for some time.

Still to do is tracking source positions which will be done in a
followup CL.

BUG=v8:4766
LOG=N

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

Cr-Commit-Position: refs/heads/master@{#34321}
2016-02-26 11:04:55 +00:00
mstarzinger
6acee6ee59 [interpreter] Make setting of function data more resilient.
This adds explicit setters for the SharedFunctionInfo::function_data
field. Such setters are safer because they allow for explicit checking
of which values are allowed, and they improve readability because the
intended semantics become clear for each call-site. Also fix a cctest
case along the way.

R=rmcilroy@chromium.org

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

Cr-Commit-Position: refs/heads/master@{#34297}
2016-02-25 16:07:24 +00:00
bmeurer
bda527b5ff [turbofan] Add support for SOFT deopts and use that for property access.
Up until now we were unable to (re)optimize code when we hit
uninitialized (Keyed)Load/StoreICs in the code. We always put an IC
there (sharing the feedback vector with fullcodegen at least) and called
it a day. But we never deoptimized the code object when we gathered more
feedback. This doesn't work very well in practice, esp. with hot code
relying on this. So until we have a proper mechanism to express the need
to reoptimize after we gathered additional feedback from optimized code,
we follow the Crankshaft approach instead and install a SOFT deopt, so
we can not only learn but also utilize the new feedback.

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

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

Cr-Commit-Position: refs/heads/master@{#34178}
2016-02-20 19:06:20 +00:00
fmeawad
c6279388c7 Split the TRACE_EVENTs from the LOG/HistogramTimers/TimerEvents functionality.
This CL adds a TRACE_EVENT where there is an isolated LOG, a HistogramTimer
or a TimerEvent.

Once we have a d8 tracing controller, all TimerEvents will be removed since
they do not provide an added value over TRACE_EVENTs. HistogramTimers will
remain, but their functionality will be limited to Histograms only.

BUG=v8:4562
LOG=N

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

Cr-Commit-Position: refs/heads/master@{#34099}
2016-02-18 06:13:33 +00:00
cbruni
8eb09facb5 [counters] adding more counters and trace-events
V8 tracks already most useful information, but lacks proper tracing scopes
that make it possible to distinguish certain events from each other.
- add trace-scope to track lazy-parsing due to optimization
- add trace-scope to track code optimization

BUG=

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

Cr-Commit-Position: refs/heads/master@{#34002}
2016-02-15 17:29:32 +00:00
mstarzinger
1986a486bf [interpreter] CompilationInfo::unoptimized_code only for OSR.
The field in question is only needed when the optimizing compiler is
triggered via OSR. All other paths (e.g. from bytecode stream) should
not rely on the unoptimized code being present.

R=yangguo@chromium.org

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

Cr-Commit-Position: refs/heads/master@{#33860}
2016-02-10 10:28:12 +00:00
mstarzinger
582be2ba09 [interpreter] Make it possible to optimize without parse.
This makes sure we can run through the TurboFan pipeline without having
to parse the source when using the bytecode stream as input. This path
is now being tested by the BytecodeGraphTester helper.

R=titzer@chromium.org,rmcilroy@chromium.org

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

Cr-Commit-Position: refs/heads/master@{#33856}
2016-02-10 09:16:38 +00:00
mstarzinger
b881c908a1 Switch GetConcurrentlyOptimizedCode to MaybeHandle.
The function in question can already return an empty handle in the case
of failures. This makes that contract explicit by using MaybeHandle like
all other compiler API functions.

R=yangguo@chromium.org

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

Cr-Commit-Position: refs/heads/master@{#33839}
2016-02-09 09:47:57 +00:00
yangguo
8a2d571734 [bootstrapper] extra natives must not use natives syntax.
R=bmeurer@chromium.org, domenic@chromium.org

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

Cr-Commit-Position: refs/heads/master@{#33770}
2016-02-05 12:33:55 +00:00
mvstanton
3f36e658c8 Revert of Type Feedback Vector lives in the closure (patchset #2 id:40001 of https://codereview.chromium.org/1668103002/ )
Reason for revert:
Must revert for now due to chromium api natives issues.

Original issue's description:
> Type Feedback Vector lives in the closure
>
> (RELAND: the problem before was a missing write barrier for adding the code
> entry to the new closure. It's been addressed with a new macro instruction
> and test. The only change to this CL is the addition of two calls to
> __ RecordWriteCodeEntryField() in the platform CompileLazy builtin.)
>
> We get less "pollution" of type feedback if we have one vector per native
> context, rather than one for the whole system. This CL moves the vector
> appropriately.
>
> We rely more heavily on the Optimized Code Map in the SharedFunctionInfo. The
> vector actually lives in the first slot of the literals array (indeed there is
> great commonality between those arrays, they can be thought of as the same
> thing). So we make greater effort to ensure there is a valid literals array
> after compilation.
>
> This meant, for performance reasons, that we needed to extend
> FastNewClosureStub to support creating closures with literals. And ultimately,
> it drove us to move the optimized code map lookup out of FastNewClosureStub
> and into the compile lazy builtin.
>
> The heap change is trivial so I TBR Hannes for it...
> Also, Yang has had a look at the debugger changes already and approved 'em. So he is TBR style too.
> And Benedikt reviewed it as well.
>
> TBR=hpayer@chromium.org, yangguo@chromium.org, bmeurer@chromium.org
>
> BUG=
>
> Committed: https://crrev.com/bb31db3ad6de16f86a61f6c7bbfd3274e3d957b5
> Cr-Commit-Position: refs/heads/master@{#33741}

TBR=bmeurer@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/1670813005

Cr-Commit-Position: refs/heads/master@{#33766}
2016-02-05 10:48:35 +00:00
mvstanton
bb31db3ad6 Type Feedback Vector lives in the closure
(RELAND: the problem before was a missing write barrier for adding the code
entry to the new closure. It's been addressed with a new macro instruction
and test. The only change to this CL is the addition of two calls to
__ RecordWriteCodeEntryField() in the platform CompileLazy builtin.)

We get less "pollution" of type feedback if we have one vector per native
context, rather than one for the whole system. This CL moves the vector
appropriately.

We rely more heavily on the Optimized Code Map in the SharedFunctionInfo. The
vector actually lives in the first slot of the literals array (indeed there is
great commonality between those arrays, they can be thought of as the same
thing). So we make greater effort to ensure there is a valid literals array
after compilation.

This meant, for performance reasons, that we needed to extend
FastNewClosureStub to support creating closures with literals. And ultimately,
it drove us to move the optimized code map lookup out of FastNewClosureStub
and into the compile lazy builtin.

The heap change is trivial so I TBR Hannes for it...
Also, Yang has had a look at the debugger changes already and approved 'em. So he is TBR style too.
And Benedikt reviewed it as well.

TBR=hpayer@chromium.org, yangguo@chromium.org, bmeurer@chromium.org

BUG=

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

Cr-Commit-Position: refs/heads/master@{#33741}
2016-02-04 15:41:23 +00:00
rmcilroy
72d768d1f9 Add counters to trace baseline code size.
BUG=v8:4280
LOG=N

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

Cr-Commit-Position: refs/heads/master@{#33688}
2016-02-02 16:51:46 +00:00
mvstanton
a702785156 Revert of Type Feedback Vector lives in the closure (patchset #2 id:20001 of https://codereview.chromium.org/1642613002/ )
Reason for revert:
Bug: failing to use write barrier when writing code entry into closure.

Original issue's description:
> Reland of Type Feedback Vector lives in the closure
>
> (Fixed a bug found by nosnap builds.)
>
> We get less "pollution" of type feedback if we have one vector per native
> context, rather than one for the whole system. This CL moves the vector
> appropriately.
>
> We rely more heavily on the Optimized Code Map in the SharedFunctionInfo. The
> vector actually lives in the first slot of the literals array (indeed there is
> great commonality between those arrays, they can be thought of as the same
> thing). So we make greater effort to ensure there is a valid literals array
> after compilation.
>
> This meant, for performance reasons, that we needed to extend
> FastNewClosureStub to support creating closures with literals. And ultimately,
> it drove us to move the optimized code map lookup out of FastNewClosureStub
> and into the compile lazy builtin.
>
> The heap change is trivial so I TBR Hannes for it...
>
> TBR=hpayer@chromium.org
> BUG=
>
> Committed: https://crrev.com/d984b3b0ce91e55800f5323b4bb32a06f8a5aab1
> Cr-Commit-Position: refs/heads/master@{#33548}

TBR=bmeurer@chromium.org,yangguo@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/1643533003

Cr-Commit-Position: refs/heads/master@{#33556}
2016-01-27 15:05:38 +00:00
mvstanton
d984b3b0ce Reland of Type Feedback Vector lives in the closure
(Fixed a bug found by nosnap builds.)

We get less "pollution" of type feedback if we have one vector per native
context, rather than one for the whole system. This CL moves the vector
appropriately.

We rely more heavily on the Optimized Code Map in the SharedFunctionInfo. The
vector actually lives in the first slot of the literals array (indeed there is
great commonality between those arrays, they can be thought of as the same
thing). So we make greater effort to ensure there is a valid literals array
after compilation.

This meant, for performance reasons, that we needed to extend
FastNewClosureStub to support creating closures with literals. And ultimately,
it drove us to move the optimized code map lookup out of FastNewClosureStub
and into the compile lazy builtin.

The heap change is trivial so I TBR Hannes for it...

TBR=hpayer@chromium.org
BUG=

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

Cr-Commit-Position: refs/heads/master@{#33548}
2016-01-27 12:53:42 +00:00
mvstanton
e2e7dc32ef Revert of Type Feedback Vector lives in the closure (patchset #12 id:260001 of https://codereview.chromium.org/1563213002/ )
Reason for revert:
FAilure on win32 bot, need to investigate webkit failures.

Original issue's description:
> Type Feedback Vector lives in the closure
>
> We get less "pollution" of type feedback if we have one vector per native
> context, rather than one for the whole system. This CL moves the vector
> appropriately.
>
> We rely more heavily on the Optimized Code Map in the SharedFunctionInfo. The
> vector actually lives in the first slot of the literals array (indeed there is
> great commonality between those arrays, they can be thought of as the same
> thing). So we make greater effort to ensure there is a valid literals array
> after compilation.
>
> This meant, for performance reasons, that we needed to extend
> FastNewClosureStub to support creating closures with literals. And ultimately,
> it drove us to move the optimized code map lookup out of FastNewClosureStub
> and into the compile lazy builtin.
>
> The heap change is trivial so I TBR Hannes for it...
>
> TBR=hpayer@chromium.org
>
> BUG=
>
> Committed: https://crrev.com/a5200f7ed4d11c6b882fa667da7a1864226544b4
> Cr-Commit-Position: refs/heads/master@{#33518}

TBR=bmeurer@chromium.org,akos.palfi@imgtec.com
# 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/1632993003

Cr-Commit-Position: refs/heads/master@{#33520}
2016-01-26 15:02:29 +00:00
mvstanton
a5200f7ed4 Type Feedback Vector lives in the closure
We get less "pollution" of type feedback if we have one vector per native
context, rather than one for the whole system. This CL moves the vector
appropriately.

We rely more heavily on the Optimized Code Map in the SharedFunctionInfo. The
vector actually lives in the first slot of the literals array (indeed there is
great commonality between those arrays, they can be thought of as the same
thing). So we make greater effort to ensure there is a valid literals array
after compilation.

This meant, for performance reasons, that we needed to extend
FastNewClosureStub to support creating closures with literals. And ultimately,
it drove us to move the optimized code map lookup out of FastNewClosureStub
and into the compile lazy builtin.

The heap change is trivial so I TBR Hannes for it...

TBR=hpayer@chromium.org

BUG=

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

Cr-Commit-Position: refs/heads/master@{#33518}
2016-01-26 14:21:08 +00:00
rmcilroy
befe61fa3e [Interpreter] Add native function literal support.
Adds support for calling native function literals. Moves the logic for building
the native function's SharedFunctionInfo out of full-codegen into compiler.cc
to allow it to be shared between fullcodegen and Ignition.

BUG=v8:4686
LOG=N

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

Cr-Commit-Position: refs/heads/master@{#33510}
2016-01-26 11:30:46 +00:00
mstarzinger
b707ca4b54 [interpreter] Deprecate --ignition-fallback-on-catch flag.
The current support for try-catch in the interpreter can handle most of
the cases appearing in our test suite. Also the flag in question did not
detect try-finally constructs. This removes the flag and instead extends
the test expectations.

R=rmcilroy@chromium.org
BUG=v8:4674
LOG=n

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

Cr-Commit-Position: refs/heads/master@{#33494}
2016-01-25 15:57:51 +00:00
danno
d1d0196473 [compiler] Remove CodeStub from CompilationInfo
The motivation for this is that CompilationInfo really shouldn't
explicitly know anything about CodeStubs. This is evident in
the TurboFan stubs pipeline, which only needs to pass down
information about Code::Flags to the code generator and not
any of the CallInterfaceDescriptor silliness that Hydrogen has
to push around, since TF has the Linkage class that
encapsulates everything that is needed for the stub ABI. So,
instead of threading CodeStub machinery through the TF stub
pipeline, it is now removed from CompilationInfo and replaced
by only the explicit bits needed both by the Crankshaft and
TF pipelines in code generation.

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

Cr-Commit-Position: refs/heads/master@{#33410}
2016-01-20 15:18:14 +00:00
rmcilroy
43c02e49d8 [Interpreter] Change ignition fallback flag to only fallback on catch, not eval.
Now that we support eval in Ignition, remove the fallback for eval checks
and make the flag only fallback on catch blocks.

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

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

Cr-Commit-Position: refs/heads/master@{#33384}
2016-01-19 11:33:50 +00:00
mstarzinger
8041a753ca Drop "current_code" from compiler API.
This removes the need to pass in the current unoptimized code when
requesting optimized code for a function. Note that the notion of
unoptimized code becomes moot when optimizing from the interpreter
bytecode, hence the API should not encode such a dependency.

R=bmeurer@chromium.org

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

Cr-Commit-Position: refs/heads/master@{#33353}
2016-01-18 10:24:22 +00:00
mstarzinger
0aeaf0cbd1 Move SourcePosition into separate header file.
This splits out the SourcePosition class into a separate header file.
Reason for this refactoring is that said class is mostly used by the
Crankshaft compiler and not needed for all compilers. Also having the
assembler depend on the class creates a dependency cycle.

R=bmeurer@chromium.org

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

Cr-Commit-Position: refs/heads/master@{#33325}
2016-01-15 12:11:50 +00:00
jarin
964964541d [turbofan] Fix turbofan-enabling conditions.
This restricts turbofan to turbofan-supported subset for the shipping
configuration ("use asm" and features unsupported by Crankshaft).

Without this, we compile with Turbofan even when there is
try-catch-finally as long as the function is "use asm" or
it contains a feature unsupported by crankshaft but supported
by turbofan (e.g., 'with' statement).

BUG=

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

Cr-Commit-Position: refs/heads/master@{#33085}
2016-01-04 14:53:07 +00:00