Review-Url: https://codereview.chromium.org/2670183004
Cr-Commit-Position: refs/heads/master@{#42921}

The operator in question does not call arbitrary JavaSciprt, nor throw,
nor trigger a lazy deoptimization. Nodes hence do not need a frame-state
representing the "after" state of the operation.

R=bmeurer@chromium.org

Review-Url: https://codereview.chromium.org/2672763002
Cr-Commit-Position: refs/heads/master@{#42891}

The %_ClassOf intrinsic roughly corresponds to the deprecated ES5
[[Class]] internal property, and should not be used anymore ideally.
However since we still have quite a couple of uses of this intrinsic
in the self hosted JavaScript builtins, we would tank some builtins
like Map, Set, WeakMap, WeakSet, etc. quite significantly unless we
also support this intrinsic until the builtins are all migrated to
C++/CSA builtins.

R=yangguo@chromium.org
BUG=v8:5267

Review-Url: https://codereview.chromium.org/2647833004
Cr-Commit-Position: refs/heads/master@{#42530}

This is so that a NotSuperConstructor error is thrown before evaluating the
arguments to the super constructor. Besides updating the runtime function, a
new bytecode GetSuperConstructor is introduced.

BUG=v8:5336

Review-Url: https://codereview.chromium.org/2504553003
Cr-Commit-Position: refs/heads/master@{#41788}

BUG=

Review-Url: https://codereview.chromium.org/2558443002
Cr-Commit-Position: refs/heads/master@{#41511}

Review-Url: https://codereview.chromium.org/2467513002
Cr-Commit-Position: refs/heads/master@{#40712}

This CL removes code that is now unused since the port of regexp.js has been
completed. Removed functions / classes are:

* regexp.js (GetSubstitution moved to string.js)
* RegExpConstructResult stub
* RegExpFlags intrinsic
* RegExpSource intrinsic
* RegExpInitializeAndCompile runtime function

BUG=v8:5339

Review-Url: https://codereview.chromium.org/2448463002
Cr-Commit-Position: refs/heads/master@{#40547}

The whitelist is populated with those inline intrinsics that are lowered
in JSIntrinsicInlining and were not previously blacklisted. Thus the only
additional FrameStates this CL adds are those where the caller tries to
call the INLINE version of an intrinsic but ends up calling the RUNTIME
version instead.

R=bmeurer@chromium.org
BUG=chromium:644631

Review-Url: https://codereview.chromium.org/2331543002
Cr-Commit-Position: refs/heads/master@{#39357}

We really just need representation information from the CallInterfaceDescriptor. This change allows us to keep that, get away from Type, and it's Zone-based allocation as well.

BUG=

Review-Url: https://codereview.chromium.org/2301883002
Cr-Commit-Position: refs/heads/master@{#39105}

This way, many files which only need CompilationInfo but not compiler.h
and its dependencies can include just compilation-info.h.

BUG=

Review-Url: https://codereview.chromium.org/2284313003
Cr-Commit-Position: refs/heads/master@{#39038}

Introduced MachineType::TaggedSigned() and TaggedPointer().

The idea is to quit using the representational dimension of Type, and
instead encode this information in the MachineRepresentation (itself
lightly wrapped in MachineType, along with MachineSemantic).

There are three parts to the whole change:

1) Places that set the machine representation - constant nodes, loads nad
   stores, global object and native context specialization.

2) Places that propagate type/representation - this is representation
   inference (aka simplified lowering). At the end of this process we
   expect to have a MachineRepresentation for every node. An interesting
   part of this is phi merging.

3) Places that examine representation - WriteBarrier elimination does this.
   Currently it's looking at the Type representation dimension, but as
   a part of this change (or in a soon-to-follow change) it can simply
   examine the MachineRepresentation.

BUG=

Review-Url: https://codereview.chromium.org/2258073002
Cr-Commit-Position: refs/heads/master@{#38978}

These JavaScript operators were special hacks to ensure that we always
operate on Smis for the magic for-in index variable, but this never
really worked in the OSR case, because the OsrValue for the index
variable didn't have the proper information (that we have for the
JSForInPrepare in the non-OSR case).

Now that we have loop induction variable analysis and binary operation
hints, we can just use JSLessThan and JSAdd instead with appropriate
Smi hints, which handle the OSR case by inserting Smi checks (that are
always true). Thanks to OSR deconstruction and loop peeling these Smi
checks will be hoisted so they don't hurt the OSR case too much.

Drive-by-change: Rename the ForInDone bytecode to ForInContinue, since
we have to lower it to JSLessThan to get the loop induction variable
goodness.

R=epertoso@chromium.org
BUG=v8:5267

Review-Url: https://codereview.chromium.org/2289613002
Cr-Commit-Position: refs/heads/master@{#38968}

BUG=

Review-Url: https://codereview.chromium.org/2259883002
Cr-Commit-Position: refs/heads/master@{#38758}

The machine types were incorrect for the runtime function and argument
count parameters. The latter was introduced in 3e2085eb, while the
former seems to always have been wrong.

This was not an issue so far because GetRuntimeCallDescriptor was only
called after the representation selection phase and thus the machine
type was ignored.

R=jarin@chromium.org
BUG=

Review-Url: https://codereview.chromium.org/2250863004
Cr-Commit-Position: refs/heads/master@{#38720}

This CL separates the check whether something is tail-callable from
the computation of the size of the stack parameters that a function
takes.

In order to track this precisely, the stack parameter size calculation
uses the recently landed MachineType information that's embedded
in return and parameter value LinkageLocations.

Review-Url: https://codereview.chromium.org/2121753002
Cr-Commit-Position: refs/heads/master@{#37668}

Remove obsolete definitions from macros.py, and drop the now obsolete
%_ToPrimitive, %_ToPrimitive_Number, %_ToPrimitive_String, %_ToName
and the %ToPrimitive_String intrinsics/runtime entries.

R=yangguo@chromium.org
BUG=v8:5049

Review-Url: https://codereview.chromium.org/2137203002
Cr-Commit-Position: refs/heads/master@{#37665}

By adding MachineType to LinkageLocation, it is possible not only to reason
about the location of a LinkageLocation on the stack, but also about it's
size. This will be useful in follow-on CLs that attempt to merge some of the
parameter passing logic of tail calls and normal (non-tail) calls.

As a nice side-effect, it is no longer necessary to separately keep a
MachineSignature in a CallDescriptor, because the MachineTypes contianed in
LinkageLocation for all of the Descriptor's parameters and return types are
sufficient. This CL therefore removes the MachineSignature from the
CallDescriptor and adjusts all the calling code accordingly, simplifying and
de-duplicating code in a bunch of places.

R=titzer@chromium.org, bmeurer@chromium.org
LOG=N

Review-Url: https://codereview.chromium.org/2124023003
Cr-Commit-Position: refs/heads/master@{#37633}

This optimizes the passing of stack parameters in function calls.

For some architectures (ia32/x64), using pushes when possible instead
of bumping the stack and then storing parameters generates much
smaller code, and in some cases is faster (e.g. when a push of a memory
location can implement a memory-to-memory copy and thus elide an
intermediate load. On others (e.g. ARM), the benefit is smaller, where
it's only possible to elide direct stack pointer adjustment in certain cases
or combine multiple register stores into a single instruction in other limited
situations. On yet other platforms (ARM64, MIPS), there are no push instructions,
and this optimization isn't used at all.

Ideally, this mechanism would be used for both tail calls and normal calls,
but "normal" calls are currently pretty efficient, and tail calls are very
inefficient, so this CL sets the bar low for building a new mechanism to
handle parameter pushing that only needs to raise the bar on tail calls for now.

The key aspect of this change is that adjustment to the stack pointer
for tail calls (and perhaps later real calls) is an explicit step separate from
instruction selection and gap resolution, but aware of both, making it possible
to safely recognize gap moves that are actually pushes.

Review-Url: https://codereview.chromium.org/2082263002
Cr-Commit-Position: refs/heads/master@{#37477}

This adds a missing lazy bailout point when defining data properties
with computed property names in object literals. The runtime call to
Runtime::kDefineDataPropertyInLiteral can trigger deopts. The necessary
bailout ID already exists and is now properly used.

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

Review-Url: https://codereview.chromium.org/2099133003
Cr-Commit-Position: refs/heads/master@{#37294}

This removes the frame state input representing the before-state from
nodes having the {JSCallRuntime} operator. These frame states can by now
be found via checkpoints in the graph. It also makes the predicate for
runtime function ids (i.e. {Linkage::NeedsFrameStateInput}) binary.

R=jarin@chromium.org
BUG=v8:5021

Review-Url: https://codereview.chromium.org/2018353004
Cr-Commit-Position: refs/heads/master@{#36679}

This removes the frame state input representing the before-state from
nodes having the {JSCallFunction} or {JSCallConstruct} operator. These
frame states can by now be found via checkpoints in the graph.

R=bmeurer@chromium.org
BUG=v8:5021

Review-Url: https://codereview.chromium.org/2025573003
Cr-Commit-Position: refs/heads/master@{#36669}

Introduce three new JS operators in Turbofan:
- JSGeneratorStore is used in implementing Ignition's SuspendGenerator bytecode.
- JSGeneratorRestoreContinuation and JSGeneratorRestoreRegister are used in
  implementing Ignition's ResumeGenerator bytecode.

Remove the runtime functions that were used to implement these bytecodes before.

BUG=v8:4907

Review-Url: https://codereview.chromium.org/1991203002
Cr-Commit-Position: refs/heads/master@{#36395}

By now the runtime entry function in question is a duplicate of the
existing Runtime_ToFastProperties function. This just gets rid of the
duplication.

R=bmeurer@chromium.org

Review-Url: https://codereview.chromium.org/1963973003
Cr-Commit-Position: refs/heads/master@{#36161}

In the bytecode graphbuilder, translate the two generator-specific
bytecodes as a couple of runtime calls for now.

BUG=v8:4907
LOG=n

Review-Url: https://codereview.chromium.org/1957393004
Cr-Commit-Position: refs/heads/master@{#36134}

Further refactor the pipeline to even run the first scheduler (part of
the effect control linearization) concurrently. This temporarily
disables most of the write barrier elimination, but we will get back to
that later.

Drive-by-fix: Remove the dead code from ChangeLowering, and stack
allocate the Typer in the pipeline. Also migrate the AllocateStub to a
native code builtin, so that we have the code object + a handle to it
available all the time.

CQ_INCLUDE_TRYBOTS=tryserver.v8:v8_linux64_tsan_rel
R=mstarzinger@chromium.org
BUG=v8:4969
LOG=n

Review-Url: https://codereview.chromium.org/1926023002
Cr-Commit-Position: refs/heads/master@{#35918}

This introduces a dedicated getter to extract call descriptors from
operators of call nodes (i.e. call and tail-call) to ensure that all
accesses are const-correct. An implicit cast of constness is undefined
behavior and hard to spot without sanitization.

R=jarin@chromium.org

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

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

The current context is stored as a stack slot on the interpreter frame
and therefore we don't need to also maintain a machine register for the
context. Removes this register from bytecode handlers.

In the process modifies this frees up a register on ia32 to keep the
dispatch table pointer in a register rather than on a stack slot on
ia32.

BUG=v8:4280
LOG=N

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

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

Modifies Ignition to store code entry addresses in the dispatch table
rather than code objects. This allows the interpreter to avoid
calculating the code entry address from the code object on every
dispatch and provides a ~5-7% performance improvement on Octane with
Ignition.

This change adds ArchOpcode::kArchTailCallAddress to TurboFan to enable
tail call dispatch using these code addresses. It also adds a Dispatch
linkage creator (distinct from the stub linkage type used previously) to
allow targetting a code address target (which will diverge further from
the stub linkage type when we remove the context machine register in
Ignition).

BUG=v8:4280
LOG=N

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

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

Now that the SharedFunctionInfo is available to compilers all of the
time, we no longer need to rely on the literal for source printing.

R=titzer@chromium.org

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

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

This should help speeding up Promise and RegExp instantiations substantially.

BUG=

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

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

This mechanism was used to ensure that functions ended up as constants on the map of prototypes defined using object literals, e.g.,:

function.prototype = {
  method: function() { ... }
}

Nowadays we treat prototypes specially, and make all their functions constants when an object turns prototype. Hence this special custom code isn't necessary anymore.

This also affects boilerplates that do not become prototypes. Their functions will not be constants but fields instead. Calling their methods will slow down. However, multiple instances of the same boilerplate will stay monomorphic. We'll have to see what the impact is for such objects, but preliminary benchmarks do not show this as an important regression.

BUG=chromium:593008
LOG=n

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

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

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}

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}

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}

Rename the existing (patching) ToBooleanStub to ToBooleanICStub to match
our naming convention, and add a new TurboFan-powered ToBooleanStub,
which just does the ToBoolean conversion without any runtime call or
code patching, so we can use it for Ignition (and TurboFan).

Drive-by-fix: Add an Oddball::to_boolean field similar to the ones we
already have for to_string and to_number, so we don't need to actually
dispatch on the concrete Oddball at all.

R=epertoso@chromium.org, rmcilroy@chromium.org, yangguo@chromium.org

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

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

The %TailCall runtime entry and the %_TailCall intrinsic is not used,
and will never be used (because %TailCall doesn't actually do a tail
call). We will soon have proper ES6 tail calls, which are correct and
properly tested.

The %Apply runtime entry is basically a super-slow, less correct version
of Reflect.apply, so we can as well just use Reflect.apply, which is
exposed to builtins via %reflect_apply.

R=ishell@chromium.org

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

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

The LazyBailout operator (modelled as a nop-call) was introduced for
placing a deoptimization point into exception handlers. Now that we are
no longer re-entering lazy deoptimized code, the support can be removed.

R=jarin@chromium.org
BUG=v8:4195
LOG=n

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

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

Initially we were unable to address certain stack slots in the callee
part of the frame, including the function marker, therefore we had to
hack a reload of the function register into the OSR prologue. Now that
we are able to address all stack slots, we no longer need this hack.

R=jarin@chromium.org

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

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

This removes support for the %Arguments and %ArgumentsLength runtime
entries and their intrinsic counterparts. If you need variable arguments
in any builtin, either use (strict) arguments object or rest parameters,
which are both compositional across inlining (in TurboFan), and not that
much slower compared to the %_Arguments hackery.

R=jarin@chromium.org

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

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

Moves InterpreterAssembler out of the compiler directory and into the
interpreter directory. Makes InterpreterAssembler as subclass of
CodeStubAssembler.

As part of this change, the special bytecode dispatch linkage type
is removed and instead we use a InterfaceDispatchDescriptor and
a normal CodeStub linkage type.

Removes a bunch of duplicated logic in InterpreterAssembler and
instead uses the CodeStubAssembler logic. Refactors Interpreter
with these changes.

Modifies CodeStubAssembler to add the extra operations required
by the Interpreter (extra call types, raw memory access and some extra
binary ops). Also adds the ability for subclasses to add extra
prologue and epilogue operations around calls, which is required
for the Interpreter.

BUG=v8:4280
LOG=N

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

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