SetForceInlineFlag is now only used in tests. Earlier, it was also used
in js builtins, because unless this flag was specified the js builtins
were not inlined. All the performance critical js builtins are moved
to turbofan builtins and SetForceInlineFlag is no longer used. We would
like to remove this flag completely to simplify inlining heuristics.
Also, this uses a bit on the SharedFuntionInfo.
Bug: v8:6682
Change-Id: I19afd27381afc212f29179f2c5477095c8174f39
Reviewed-on: https://chromium-review.googlesource.com/660739
Commit-Queue: Mythri Alle <mythria@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47997}
Moves ast printing out of codegen.cc and into interpreter.cc since this is
the only place which calls it.
BUG=v8:6409
Change-Id: I7b730f6b4da76247f57e3cb4fa7895e638ea0517
Reviewed-on: https://chromium-review.googlesource.com/664888
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Mythri Alle <mythria@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47996}
For the HeapNumber case, use Float64Neg directly instead of a
Float64Mul by -1.0.
For the Smi case, logic is added to handle the boundary conditions
(0 and Smi::kMinValue), and the general case is handled by a SmiSub
from 0.
Change-Id: I110916d9d1eb5d22d618fbf358d8d5b63cc71b3a
Reviewed-on: https://chromium-review.googlesource.com/663945
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Commit-Queue: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47995}
In the years since https://codereview.chromium.org/1331993004, a lot has
changed in v8: Math.max/min are now CSA builtins, with lowerings in
TF.
In a quick test on my machine of the microbenchmark on that CL
(modified with start and end values), I don't detect any difference
in speed between the macro versions on master and this version.
Cq-Include-Trybots: master.tryserver.v8:v8_linux_noi18n_rel_ng
Change-Id: I82d9d14c043fd2a112050cdbcb98a872bfb87b61
Reviewed-on: https://chromium-review.googlesource.com/664339
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47994}
We introduce an explicit LoweringResult data structure. Until this change,
the lowering result could be recovered from the node. However, lowering
monomorphic loads requires wiring different value and effect, so we need
a structure that can express such lowering result.
Bug: v8:6357
Change-Id: I92655800890b744d9203a778a1936a8dcd465ed3
Reviewed-on: https://chromium-review.googlesource.com/637304
Commit-Queue: Jaroslav Sevcik <jarin@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47992}
We reset the profiler ticks when the feedback changes. So, we should
not update the feedback when the feedback hasn't changed. Added a
check in IC::ConfigureVectorState to see if the feedback has changed
before we update the feedback.
Bug:
Change-Id: I83f38656b52df7f687cd0c2eceac961dcd4f35f7
Reviewed-on: https://chromium-review.googlesource.com/657698
Commit-Queue: Mythri Alle <mythria@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47988}
* Inline src/runtime/runtime-typedarray.cc's TypedArrayCopyElements to
avoid clash with src/builtins/builtins-typedarray.cc
* #undef V after its last use in src/asmjs/asm-scanner.cc
* Convince clang that it's ok that frame_content_ is never used in
src/deoptimizer.h
Bug: chromium:746958
Change-Id: Ibef589b66384d982a8463c3f05b9db9c4fd92ce0
Reviewed-on: https://chromium-review.googlesource.com/663858
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Mostyn Bramley-Moore <mostynb@opera.com>
Cr-Commit-Position: refs/heads/master@{#47986}
The Object.keys builtin didn't properly check for
empty_slow_elements_dictionary in addition to empty_fixed_array,
which made it miss the fast-path if you used it in combination with
like Object.freeze or Object.seal. This adds the missing fast-path
support.
Bug: v8:6767
Change-Id: I48e43b2ee51eb2d48446c45748401af096020bb7
Reviewed-on: https://chromium-review.googlesource.com/663539
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47985}
We assume that at this point the platform always exists. If this
assumption fails we have to reconsider how we call foreground tasks from
background tasks.
R=clemensh@chromium.org
Bug: chromium:764313
Change-Id: Ic2e61adc138cdf969f5b0bdf7702e839df5846b9
Reviewed-on: https://chromium-review.googlesource.com/663717
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47983}
Before we used to require compiled debugger script to report Scopes.
After migration inspection to brand-new native API we can report
Scopes all the time and remove this hidden dependency.
R=dgozman@chromium.org
Bug: none
Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel
Change-Id: I3530bc7ead691a51073e384aea4a4ef428dc94da
Reviewed-on: https://chromium-review.googlesource.com/662097
Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org>
Reviewed-by: Dmitry Gozman <dgozman@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47982}
Some API functions have no context and debug::ScopeIterator::
CreateForFunction is crashing on attempt to get context.
R=jgruber@chromium.org
Bug: chromium:759913
Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel
Change-Id: I0a9861ea2d19bceff97c4394b34a8dda45222b78
Reviewed-on: https://chromium-review.googlesource.com/661789
Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47981}
This continues to move the "desugaring" of unary operators further
down the pipeline, in this case into the bytecode handlers for new
bytecodes `Negate` and `BitwiseNot` and the corresponding TF code
in BytecodeGraphBuilder.
Bug: v8:6971
Tbr: yangguo@chromium.org
Change-Id: If6b5d6b239a09ef8b4dbde49321614503c0f5beb
Reviewed-on: https://chromium-review.googlesource.com/661146
Commit-Queue: Adam Klein <adamk@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47980}
As part of that change, make ToNumber return in the accumulator.
Bug: v8:6791
Change-Id: I8ce0f4fbc7ad8ee7fb4a32a8a499394395010750
Reviewed-on: https://chromium-review.googlesource.com/658082
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47976}
Merge some stack operations to work on an even number of registers, adding
a padding register where necessary. Some lightly-used macro assembler
functions are inlined, to make pairing registers easier. Not all merges
create an even number of register arguments yet.
This is a step towards aligning the stack pointer to 16-bytes.
Bug: v8:6644
Change-Id: I995510cf91fa1f7af659a8d9b83acf7857787100
Reviewed-on: https://chromium-review.googlesource.com/654607
Commit-Queue: Martyn Capewell <martyn.capewell@arm.com>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47975}
During JSTypedLowering, when we see a JSAdd where we know that at least
one side is already a String, we can try to strength-reduce the other
side to a string as well. And once we have that, check whether both
sides are now String constants, and if the concatenation won't overflow
the string length limit, we can just constant-fold the StringAdd.
This improves the Six Speed template_string benchmarks by up to 5x, as
we no longer need to perform the String concatenations on every loop
iteration.
Bug: v8:6815
Change-Id: I8c47b2adf66b585d2f191cf805604b435f6256cd
Also-By: jarin@chromium.org
Reviewed-on: https://chromium-review.googlesource.com/663181
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Michael Stanton <mvstanton@chromium.org>
Reviewed-by: Michael Stanton <mvstanton@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47974}
As per spec.
R=ahaas@chromium.org
Change-Id: I46d4bdd444452fef05c234688c27aad8d086bf61
Reviewed-on: https://chromium-review.googlesource.com/663457
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Andreas Rossberg <rossberg@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47973}
So far we didn't properly constant-fold JSToString operators in
JSTypedLowering where the input was a known number constant.
Bug: v8:6815
Change-Id: Iac87346b7d38f0f75461f285ea7daa2d5a5e1524
Reviewed-on: https://chromium-review.googlesource.com/663358
Reviewed-by: Michael Stanton <mvstanton@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47972}
Linux builds have an include chain from src/perf-jit.cc:
sys/mman.h -> bits/mman.h -> bits/mman-linux.h, which defines
a MAP_TYPE macro that conflicts with InstanceType::MAP_TYPE
in jumbo builds, for some jumbo_file_merge_limit values.
Since MAP_TYPE isn't used in perf-jit.cc, it should be safe
to #undef the macro immediately after the sys/mman.h #include
statement.
Bug: chromium:746958
Change-Id: I1339a4f56cf6783bf6121cd44c93e776af9458ba
Reviewed-on: https://chromium-review.googlesource.com/654042
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Commit-Queue: Mostyn Bramley-Moore <mostynb@opera.com>
Cr-Commit-Position: refs/heads/master@{#47971}
This further reduces the amount of test-specific code. It will also
help testing the wasm baseline compiler, since it is also being called
from the {WasmCompilationUnit}.
Also, move the {RuntimeExceptionSupport} flag from the
{WasmFunctionCompiler} to the {TestingModuleBuilder}. There is no need
to store this per function builder. The {TestingModuleBuilder} then
passes it on to the {WasmCompilationUnit}, which finally sets it on the
{WasmGraphBuilder}.
R=mtrofin@chromium.org
Bug: v8:6600
Change-Id: I783dc296297a5ca37a2dd0d2035d782ca19a0fee
Reviewed-on: https://chromium-review.googlesource.com/660239
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Mircea Trofin <mtrofin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47970}
We were using a boolean before, which makes the meaning non-obvious
when passed as a parameter. With the enum, you actually have to use
{kRuntimeExceptionSupport} or {kNoRuntimeExceptionSupport}.
R=mtrofin@chromium.org
Change-Id: Iaf5a7b6f1b446d4c3e16e044a6055d923d3b0b49
Reviewed-on: https://chromium-review.googlesource.com/660738
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Mircea Trofin <mtrofin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47969}
Contributed by kanghua.yu@intel.com.
Bug: None
Change-Id: I5651ef38eb0c08deb97770a5eaa985dba2dab9a9
Reviewed-on: https://chromium-review.googlesource.com/604648
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Commit-Queue: Pan Deng <pan.deng@intel.com>
Cr-Commit-Position: refs/heads/master@{#47968}
Instead of four different constructors, we actually just need one. You
either pass a Counters*, or we will get it from the isolate (which is
only allowed to happen on the main thread).
This change makes refactoring this data structure for the baseline
compiler much easier.
R=mtrofin@chromium.orgCC=kschimpf@chromium.org
Bug: v8:6600
Change-Id: I56fb47005861dd4a203373776901930a02e09deb
Reviewed-on: https://chromium-review.googlesource.com/657979
Reviewed-by: Mircea Trofin <mtrofin@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47964}
When accessing elements of a global (constant) JSArray, whose backing
store is copy-on-write, we can just constant-fold the value and insert
a check that the backing store stays the same.
Bug: v8:6816, v8:6815
Change-Id: I090bcec7b1ce72a1f9ed8625680ed91e8c67f27f
Reviewed-on: https://chromium-review.googlesource.com/662757
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47963}
- Memory.Grow with guard pages enabled should adjust amount of allocated
memory, and not allocate a new buffer. This was disabled because previously
the backing store was freed in the MemoryFinalizer, and we needed to be sure
that the backing store is not released till the last buffer using it is
released. This is now safe as we no longer use the MemoryFinalizer
- SetProtection should use Guard/Unprotect that use mprotect underneath,
instead of CommitRegion/UncommitRegion that use mmap
- Move buffer allocation to the end to avoid inconsistent memory due to GC
BUG=v8:5886
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
Change-Id: I0d7edb884bd1e3167eb5fbced6953c6401688d40
Reviewed-on: https://chromium-review.googlesource.com/629517
Reviewed-by: Brad Nelson <bradnelson@chromium.org>
Reviewed-by: Eric Holk <eholk@chromium.org>
Commit-Queue: Deepti Gandluri <gdeepti@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47960}
It causes a significant regression in TypedArray benchmarks. Thinking it
through, it is actually not necessary for the JavaScript memory model
either. I originally added it to ensure that reads/writes are not elided
or duplicated, but there is no guarantee of this behavior for non-atomic
writes in the model.
BUG=chromium:763814
R=clemensh@chromium.org
Change-Id: Ib03d2e2e77a846d4b9e84eebc7f8fbf861f8fd7c
Reviewed-on: https://chromium-review.googlesource.com/661192
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Commit-Queue: Ben Smith <binji@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47957}
BigInt is a new primitive type of arbitrary precision integers,
proposed in https://tc39.github.io/proposal-bigint.
This CL introduces a corresponding instance type, map, and C++
class to V8 and adds BigInt support to a few operations (see the
test file). Much more is to come. Also, the concrete representation
of BigInts is not yet fixed, currently a BigInt is simply a wrapped
Smi.
Bug: v8:6791
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
Change-Id: Ia2901948efd7808f17cfc945f0d56e23e8ae0b45
Reviewed-on: https://chromium-review.googlesource.com/657022
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47956}
This will introduce a new behavior on POSIX(-like) platforms. Timezone
names inside parentheses after GMT offset will not be 3-4 letter
abbreviation any longer. They'll be human-readable names in the current
default locale. This matches the current Windows behavior.
new Date(2017, 5, 22).toString()
new Date(2017, 11, 22).toString()
Current:
Thu Jun 22 2017 00:00:00 GMT-0700 (PDT)
Fri Dec 22 2017 00:00:00 GMT-0800 (PST)
New in en-US locale:
Thu Jun 22 2017 00:00:00 GMT-0700 (Pacific Daylight Time)
Fri Dec 22 2017 00:00:00 GMT-0800 (Pacific Standard Time)
New in German locale:
Thu Jun 22 2017 00:00:00 GMT-0700 (Nordamerikanische Westküsten-Sommerzeit)
Fri Dec 22 2017 00:00:00 GMT-0800 (Nordamerikanische Westküsten-Normalzeit)
BUG=v8:6031, v8:2137, v8:6076
TEST=mjsunit/icu-date-lord-howe.js, mjsunit/icu-date-to-string.js
Change-Id: I4e7fd8b3ddae5c7779e220c4c101e45904fcdc01
Reviewed-on: https://chromium-review.googlesource.com/625164
Commit-Queue: Jungshik Shin <jshin@chromium.org>
Reviewed-by: Daniel Ehrenberg <littledan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47953}
This is a reland of da6aab4319
Original change's description:
> [snapshot] Temporarily enable --lazy-deserialization
>
> Flip the flag for one day to determine impact and flush out bugs.
> Please add crashes and regressions to https://crbug.com/v8/6796.
>
> Bug: v8:6624,v8:6796
> Change-Id: I8b0581c40d956e01f94e9098ff935fdd5af36156
> Reviewed-on: https://chromium-review.googlesource.com/651408
> Commit-Queue: Jakob Gruber <jgruber@chromium.org>
> Reviewed-by: Yang Guo <yangguo@chromium.org>
> Reviewed-by: Michael Hablich <hablich@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#47893}
Bug: v8:6624, v8:6796
Change-Id: I7df43925ccb2e6c1d3455439690526b0e1a6a747
Reviewed-on: https://chromium-review.googlesource.com/660218
Reviewed-by: Michael Hablich <hablich@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47952}
Since we don't have a full-codegen compiler anymore, we no longer
generate Code::FUNCTION kind. Nice! Here is some cleanup.
Bug: v8:6409
Change-Id: I05634e4ca85c4037b49a4346f4e8bae8042b8762
Reviewed-on: https://chromium-review.googlesource.com/657817
Commit-Queue: Michael Stanton <mvstanton@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47951}
The wasm code for asm.js modules is generated by us and does not come
from the user. Therefore we do not need to check in release builds that
experimental opcodes are not used for asm.js, a DCHECK is sufficient.
R=clemensh@chromium.org
Change-Id: I0c7135bfb03eafd2a39e648d57eff8e3a4440c3f
Reviewed-on: https://chromium-review.googlesource.com/659938
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47950}
