We have an absolute limit beyond which we don't inline small funcions as
well. The idea behind inlining small functions is that it is cheaper to
inline small functions rather than incurring the overhead due to the call.
Hence it is better not to have a hard limit on inlining small functions.
We have a limit on the number of levels of nesting to avoid really large
graphs in some corner cases.
Bug: v8:6682
Change-Id: If74f666996fe4a42bf266a4e87caabfd7c614b12
Reviewed-on: https://chromium-review.googlesource.com/648975
Commit-Queue: Mythri Alle <mythria@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48007}
With this commit, write barrier is switched to use CodeStubAssembler.
Bug: chromium:749486
Change-Id: I7e0914bee971e4f3a3257740ae7c83b31f791bd9
Reviewed-on: https://chromium-review.googlesource.com/598088
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Albert Mingkun Yang <albertnetymk@google.com>
Cr-Commit-Position: refs/heads/master@{#48006}
This patch ensures that an object returned by AllocateRaw is marked
black if black allocation starts during the object allocation.
This fixes the following issue:
1) Generated code requests allocation of size N for folded allocation.
2) Runtime gets a free list node at address A of size N+M and sets up
a linear allocation area with top = A+N and limit = A+N+M.
3) Runtime invokes the allocation observer that starts incremental marking
and start black allocation. The area [A+N, A+N+M) is marked black.
4) Runtime returns a white object at address A as the allocation result.
5) Generated code moves the top pointer to A and does bump pointer
allocations of white objects from A to A+N+M.
6) Object allocated new A+N can have the impossible marbit pattern.
Bug: chromium:694255
Change-Id: I09ceebc97a510fa5fe4ff20706bc46a99f8b7cf4
Reviewed-on: https://chromium-review.googlesource.com/638338
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48005}
There are two places where RecordWrite code stub is called,
OutOfLineRecordWrite and RecordWriteField. With this commit, if
`v8_enable_csa_write_barrier` flag is turned on, no instances of the old
RecordWrite stub appear in the snapshot.
Bug: chromium:749486
Change-Id: I2bc3fa38c8831736303b46d153a79c034a450f16
Reviewed-on: https://chromium-review.googlesource.com/648983
Commit-Queue: Albert Mingkun Yang <albertnetymk@google.com>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48004}
Previously instructions-arm64.h was alternatively defining or declaring
some constants based on whether or not ARM64_DEFINE_FP_STATICS was defined,
and it was assumed that exactly one file would include this header with
the macro defined.
In jumbo builds, the header guards in instructions-arm64.h meant that the
resulting state of the header file would be whichever of the two cases
that appeared first in the compilation unit. This would cause multiple
definitions in some cases and no definitions in some other cases (or if
you were really lucky, it would work out ok).
Let's move these constants to a separate source file temporarily, to be
excluded from jumbo compilation units. This code should eventually be
replaced with a cleaner solution.
Bug: chromium:746958
Change-Id: I7edb1821ef408afd50c6b236d63d3c07f955b58f
Reviewed-on: https://chromium-review.googlesource.com/663898
Commit-Queue: Mostyn Bramley-Moore <mostynb@opera.com>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48003}
Bug: v8:6791
Change-Id: I2da258f7db6c74d764c674eb8d550418a566c5ea
Reviewed-on: https://chromium-review.googlesource.com/662138
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48002}
Extends the current implementation of WASM exceptions to be able to
throw exceptions with values (not just tags).
An JS typed array (uint_16) is used to hold thrown values, so that the
thrown values can be inspected in JS.
Bug: v8:6577
Change-Id: I1007e79ceaffd64386b62562919cfbb920fc10c5
Reviewed-on: https://chromium-review.googlesource.com/633866
Commit-Queue: Karl Schimpf <kschimpf@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Eric Holk <eholk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48001}
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}
