This is a reland of 82111e2286
Relanding since we now have more shards:
https://chromium-review.googlesource.com/c/v8/v8/+/1760810
Original change's description:
> [CSA][cleanup] TNodify some methods related to prototype and property lookup
>
> This is a CL in a string of CLs that aims to TNodify CSA. In particular,
> there were some loads that were done in AnyTagged instead of
> TaggedPointer. TNode-ifying them brings improvement in pointer
> compression since we are able to decompress using the Pointer
> decompression.
>
> TNodified:
> * LoadJSFunctionPrototype
> * TryPrototypeChainLookup
> * OrdinaryHasInstance
>
> Also TNodified loads regarding:
> * FeedbackCell::kValueOffset
> * HeapObject::kMapOffset
> * JSFunction::kSharedFunctionInfoOffset
> * JSFunction::kFeedbackCellOffset
> * Map::kInstanceTypeOffset
> * Map::kInstanceDescriptorsOffset
> * Map::kPrototypeOffset
>
> Drive-by cleanup: StoreJSArrayLength and StoreElements were unused.
>
> Bug: v8:6949, v8:9396
> Change-Id: I89697b5c02490906be1eee63cf3d9e60a1094d48
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1755844
> Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#63216}
Bug: v8:6949, v8:9396
Change-Id: I040aefcf8af60611f7b3c24f3bd5c661e03b6ada
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1760811
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63249}
This reverts commit 82111e2286.
Reason for revert: Speculative revert, could be causing timeouts - https://ci.chromium.org/p/v8/builders/ci/V8%20Linux%20-%20arm%20-%20sim%20-%20debug/17567
Original change's description:
> [CSA][cleanup] TNodify some methods related to prototype and property lookup
>
> This is a CL in a string of CLs that aims to TNodify CSA. In particular,
> there were some loads that were done in AnyTagged instead of
> TaggedPointer. TNode-ifying them brings improvement in pointer
> compression since we are able to decompress using the Pointer
> decompression.
>
> TNodified:
> * LoadJSFunctionPrototype
> * TryPrototypeChainLookup
> * OrdinaryHasInstance
>
> Also TNodified loads regarding:
> * FeedbackCell::kValueOffset
> * HeapObject::kMapOffset
> * JSFunction::kSharedFunctionInfoOffset
> * JSFunction::kFeedbackCellOffset
> * Map::kInstanceTypeOffset
> * Map::kInstanceDescriptorsOffset
> * Map::kPrototypeOffset
>
> Drive-by cleanup: StoreJSArrayLength and StoreElements were unused.
>
> Bug: v8:6949, v8:9396
> Change-Id: I89697b5c02490906be1eee63cf3d9e60a1094d48
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1755844
> Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#63216}
TBR=rmcilroy@chromium.org,solanes@chromium.org
# Not skipping CQ checks because original CL landed > 1 day ago.
Bug: v8:6949, v8:9396
Change-Id: Ib6ae8fe86a598ed1066894595565e1162cf7dd1f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1758310
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Reviewed-by: Santiago Aboy Solanes <solanes@chromium.org>
Commit-Queue: Maya Lekova <mslekova@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63233}
This is a CL in a string of CLs that aims to TNodify CSA. In particular,
there were some loads that were done in AnyTagged instead of
TaggedPointer. TNode-ifying them brings improvement in pointer
compression since we are able to decompress using the Pointer
decompression.
TNodified:
* LoadJSFunctionPrototype
* TryPrototypeChainLookup
* OrdinaryHasInstance
Also TNodified loads regarding:
* FeedbackCell::kValueOffset
* HeapObject::kMapOffset
* JSFunction::kSharedFunctionInfoOffset
* JSFunction::kFeedbackCellOffset
* Map::kInstanceTypeOffset
* Map::kInstanceDescriptorsOffset
* Map::kPrototypeOffset
Drive-by cleanup: StoreJSArrayLength and StoreElements were unused.
Bug: v8:6949, v8:9396
Change-Id: I89697b5c02490906be1eee63cf3d9e60a1094d48
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1755844
Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63216}
- Lower LoadObjectField to LoadFromObject
- Mark LoadFromObject and StoreToObject as non-allocating
- Use optimizable BitcastTaggedSignedToWord in TaggedIsNotSmi check
R=jarin@chromium.org, tebbi@chromium.org
Change-Id: I42992d46597be795aee3702018f7efd93fcc6ebf
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1657926
Commit-Queue: Georg Schmid <gsps@google.com>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62173}
We translate loads with TaggedXXX (XXX in {"", "Signed", "Pointer"})
representation in CSA into loads of CompressedXXX +
ChangeCompressedXXXToTaggedXXX in the raw-machine-assembler.
This way, CSA doesn't need to know about Compressed values since we
are introducing an explicit "decompress" node.
Also updating tests that were checking for the load nodes.
Cq-Include-Trybots: luci.v8.try:v8_linux64_pointer_compression_rel_ng
Cq-Include-Trybots: luci.v8.try:v8_linux64_arm64_pointer_compression_rel_ng
Bug: v8:8977, v8:7703
Change-Id: Ie22ca8123a25ef005c1ff7383776f9355020fa42
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1565897
Reviewed-by: Michael Stanton <mvstanton@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
Cr-Commit-Position: refs/heads/master@{#60873}
For macros expanding to function definitions, I removed the spurious ; after
macro invocations. For macros expandign to function declarations, I made the ;
required and consistently inserted it.
No behavior change.
Bug: chromium:926235
Change-Id: Ib8085d85d913d74307e3481f7fee4b7dc78c7549
Reviewed-on: https://chromium-review.googlesource.com/c/1467545
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Nico Weber <thakis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#59558}
As identified in the web-tooling-benchmark, there are specific code
patterns involving array indexed property accesses and subsequent
comparisons of those indices that lead to repeated Smi checks in the
optimized code, which in turn leads to high register pressure and
generally bad register allocation. An example of this pattern is
code like this:
```js
function f(a, n) {
const i = a[n];
if (n >= 1) return i;
}
```
The `a[n]` property access introduces a CheckBounds on `n`, which
later lowers to a `CheckedTaggedToInt32[dont-check-minus-zero]`,
however the `n >= 1` comparison has collected `SignedSmall` feedback
and so it introduces a `CheckedTaggedToTaggedSigned` operation. This
second Smi check is redundant and cannot easily be combined with the
earlier tagged->int32 conversion, since that also deals with heap
numbers and even truncates -0 to 0.
So we teach the RedundancyElimination to look at the inputs of these
speculative number comparisons and if there's a leading bounds check
on either of these inputs, we change the input to the result of the
bounds check. This avoids the redundant Smi checks later and generally
allows the SimplifiedLowering to do a significantly better job on the
number comparisons. We only do this in case of SignedSmall feedback
and only for inputs that are not already known to be in UnsignedSmall
range, to avoid doing too many (unnecessary) expensive lookups during
RedundancyElimination.
All of this is safe despite the fact that CheckBounds truncates -0
to 0, since the regular number comparisons in JavaScript identify
0 and -0 (unlike Object.is()). This also adds appropriate tests,
especially for the interesting cases where -0 is used only after
the code was optimized.
Bug: v8:6936, v8:7094
Change-Id: Ie37114fb6192e941ae1a4f0bfe00e9c0a8305c07
Reviewed-on: https://chromium-review.googlesource.com/c/1246181
Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56428}
Remove the NumberConstant right hand side limitation for the speculative
number operation optimization, and extend the logic to also deal with
SpeculativeToNumber, which is common when dealing with postfix increment
and array operations.
Also add appropriate tests for all the relevant cases, specifically we
mjsunit tests to increase the general coverage for the various cases
here (in addition to dedicated unittests).
Bug: v8:8015
Change-Id: I8c92f98490c63b07eb19686efd404322979e57c4
Reviewed-on: https://chromium-review.googlesource.com/1235919
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56072}
This replaces the previous CheckStringAdd operator which deopts in case
the combined length overflows with a dedicated pure StringConcat operator.
This operator is similar to NewConsString in that it takes the resulting
length plus the two input strings. The operator relies on the length
being checked explicitly by the surrounding code instead of baking the
check into the operator itself. This way TurboFan can eliminate
redundant/unnecessary StringConcat operations, since they are pure now.
This also unifies the treatment of string addition in JSTypedLowering,
and generalizes the StringLength constant-folding to apply to more cases
not just the JSAdd cases inside JSTypedLowering.
Bug: v8:7902, v8:8015
Change-Id: I987ec39815a9464fd5fd9c4f7b26b709f94f2b3f
Reviewed-on: https://chromium-review.googlesource.com/1213205
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#55725}
The new node is introduced for literal string addition and calling
String.prototype.concat in the typed lowering phase. It later might get optimized
away during redundancy elimination, keeping the performance of already existing
benchmarks with string addition. In case the operation is about to throw
(due to too long string being constructed) we just deoptimize, reusing
the interpreter logic for creating the error.
Modify relevant mjsunit and unit tests for string concatenation.
Bug: v8:7902
Change-Id: Ie97d39534df4480fa8d4fe3ba276d02ed5e750e3
Reviewed-on: https://chromium-review.googlesource.com/1193342
Commit-Queue: Maya Lekova <mslekova@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#55482}
This CL also removes the JSBuiltinReducer, which is no longer needed.
Bug: v8:7340, v8:7250
Change-Id: I28896f6ce0d352047ea1cb7ea6de490818840faf
Reviewed-on: https://chromium-review.googlesource.com/1027853
Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52799}
This CL changes the poisoning in the interpreter to use the
infrastructure used in the JIT.
This does not change the original flag semantics:
--branch-load-poisoning enables JIT mitigations as before.
--untrusted-code-mitigation enables the interpreter mitigations
(now realized using the compiler back-end), but does not enable
the back-end based mitigations for the Javascript JIT. So in effect
--untrusted-code-mitigation makes the CSA pipeline for bytecode handlers
use the same mechanics (including changed register allocation) that
--branch-load-poisoning enables for the JIT.
Bug: chromium:798964
Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel
Change-Id: If7f6852ae44e32e6e0ad508e9237f24dec7e5b27
Reviewed-on: https://chromium-review.googlesource.com/928881
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52243}
This CL also cleans up some related naming in typed-optimization.
R=neis@chromium.org
Bug: v8:7531, v8:7570
Change-Id: If80e0e9642aaf6c58b164db2e1e0632cd5b0d051
Reviewed-on: https://chromium-review.googlesource.com/978066
Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52182}
This also introduces two new simplified operators,
NumberIsFinite and ObjectIsFiniteNumber; the latter
handles all values, and the former is a fast-path
of the fast-path that is inserted by typed optimization
if we know the input has Type::Number.
Bug: v8:7340, v8:7250
Change-Id: I1b4812c01bf470bbff40fb3da6e11da543a22cd2
Reviewed-on: https://chromium-review.googlesource.com/951244
Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#51980}
UnalignedLoad is the only kind of load operation that defines its own
UnalignedLoadRepresentation type alias and LoadRepresentationOf function.
This is a problem because it means we cannot use the LOAD_MATCHER
infrastructure without defining all of this boilerplate for all the other
kinds of load operations. Since these aliases serve no real purpose,
it is best to unify UnalignedLoad to how its peers are handled.
Change-Id: I51a591eb82fb85edee66512136b23276e851f767
Reviewed-on: https://chromium-review.googlesource.com/951683
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#51802}
This is a reland of b8bc26d099
Original change's description:
> [turbofan] Preserve order of compares in switches
>
> This CL makes sure that control flow optimization does
> not change the order of switches that ultimately get
> lowered to a series of comparisons anyway.
>
> Bug: v8:7326
> Change-Id: If004de6b71a7e9504d37754c847ca108a64e49db
> Reviewed-on: https://chromium-review.googlesource.com/941952
> Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
> Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#51679}
Bug: v8:7326
Change-Id: Ifbe61dece499c98bbd49fa3ae9b99ccf4e955ddc
Reviewed-on: https://chromium-review.googlesource.com/945770
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
Cr-Commit-Position: refs/heads/master@{#51691}
This CL also adds speculation to all Math builtins,
and refactors the JSCallReducer.
Bug: v8:7250, v8:7240
Change-Id: Icdaddb767e875bb191939d907f65c7a8dcf79b8b
Reviewed-on: https://chromium-review.googlesource.com/873916
Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#51426}
Moves generation of speculation poison to be based on the PC target vs the
actual PC being executed. The speculation poison is generated in the prologue
of the generated code if CompilationInfo::kGenerateSpeculationPoison is set.
The result is stored in a known register, which can then be read using the
SpeculationPoison machine node.
Currently we need to ensure the SpeculationPoison node is scheduled right after
the code prologue so that the poison register doesn't get clobbered. This is
currently not verified, however it's only use is in RawMachineAssembler where
it is manually scheduled early.
The Ignition bytecode handlers are updated to use this speculation poison
rather than one generated by comparing the target bytecode.
BUG=chromium:798964
Change-Id: I2a3d0cfc694e88d7a8fe893282bd5082f693d5e2
Reviewed-on: https://chromium-review.googlesource.com/893160
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#51229}
Strings are immutable in JavaScript land (contrast with the runtime,
where we can truncate strings that haven't escaped to JavaScript yet),
so the length of a String is immutable. Thus loading the length of a
String is a pure operation and should be expressed as such (i.e. doesn't
depend on control or effect). The StringLength operator does exactly
this and is hooked up to the effect chain in the EffectControlLinearizer.
This will eventually allow us to simplify the optimization of string
concatention and other operations that are a bit cumbersome in TurboFan
currently, and it will also allow us to optimize string operations
across effectful operations, for example combining multiple invocations
to String#slice with the same inputs.
Bug: v8:5269, v8:6936, v8:7109, v8:7137
Change-Id: Iffcccbb0c7fc4cfe1281c10e7af24b40eba4c987
Reviewed-on: https://chromium-review.googlesource.com/799690
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49731}
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}
Reland d8bfdb7a99
Original commit message:
If alignment parameter is set, the memory returned by the
StackSlot operator will be aligned according to the parameter.
The implementation goes like this. If alignment parameter is set
we allocate a bit more memory than actually needed and so we
can move the beginning of the StackSlot in order to have it aligned.
BUG=
Review-Url: https://codereview.chromium.org/2874713003
Cr-Commit-Position: refs/heads/master@{#45339}
We can compile a !== a and Number.isNaN(a) to ObjectIsNaN. The former is
commonly used to check for NaN, i.e. in case of equals in AngularJS.
R=jarin@chromium.org
BUG=v8:5267
Review-Url: https://codereview.chromium.org/2722483003
Cr-Commit-Position: refs/heads/master@{#43572}
Also lower JSToBoolean(x) where x is either some detectable receiver or
null, or any kind of receiver, null or undefined. Also fix a couple of
minor issues with the JSToBoolean lowering and tests.
R=yangguo@chromium.org
BUG=v8:5267
Review-Url: https://codereview.chromium.org/2530773002
Cr-Commit-Position: refs/heads/master@{#41241}
This adds a new ExternalPointer type, which is an Internal type that is
used for ExternalReferences and other pointer values, like the pointers
into the asm.js heap. It also adds a PointerConstant operator, which we
use to represents these raw constants (we can probably remove that
particular operator again once WebAssembly ships with the validator).
R=mvstanton@chromium.org
BUG=v8:5267,v8:5270
Review-Url: https://codereview.chromium.org/2494753003
Cr-Commit-Position: refs/heads/master@{#40923}
They are nops, but will be used when verifying the machine graph.
BUG=
Review-Url: https://codereview.chromium.org/2367413002
Cr-Commit-Position: refs/heads/master@{#39758}
For denominators that are powers of two, replace Float64 division with
multiplication by the reciprocal.
Additionally, replace division by -1 with negation, and multiplication by two
with addition.
BUG=
Review-Url: https://codereview.chromium.org/2347573002
Cr-Commit-Position: refs/heads/master@{#39478}
Previously we always lowered JSToBoolean(x:Number) to the subgraph
NumberLessThan(0.0, NumberAbs(x)), which deals with both 0, -0 and
NaNs appropriately. However this doesn't always generate the best,
especially when we can later derive from feedback that x is always
an Integral32 value, where the ideal code would be just a single
comparison to 0 w/o the absolute value computation.
R=mvstanton@chromium.org
BUG=v8:5267,v8:5270
Review-Url: https://codereview.chromium.org/2309953002
Cr-Commit-Position: refs/heads/master@{#39194}
If the type of a tracked field or element value is less precise than the
advertised type of the field or element load, then we replace the load
operation with a TypeGuard that guards the advertised type.
R=jarin@chromium.org
BUG=v8:5267
Review-Url: https://codereview.chromium.org/2295643002
Cr-Commit-Position: refs/heads/master@{#39032}
Up until now "-0.0 - x" was lowered in the instruction selector. I moved
the lowering now to the MachineOperatorReducer.
I did not remove the lowering from the instruction selector yet, I would
prefer to do that in a separate CL.
R=bmeurer@chromium.org
Review-Url: https://codereview.chromium.org/2226663002
Cr-Commit-Position: refs/heads/master@{#38417}
Introduce a dedicated NumberOperationHint enum that represents the
feedback we can use for speculative number operations.
BUG=v8:4930
Review-Url: https://codereview.chromium.org/2220573002
Cr-Commit-Position: refs/heads/master@{#38411}
Drive-by fix: actually match the hint in the IsSpeculativeBinopMatcher.
Review-Url: https://codereview.chromium.org/2191883002
Cr-Commit-Position: refs/heads/master@{#38176}
Implement UnalignedLoad and UnalignedStore optional
turbofan operators and use them in WasmCompiler for unaligned
memory access.
BUG=
Review-Url: https://codereview.chromium.org/2122853002
Cr-Commit-Position: refs/heads/master@{#37988}
So far we don't have a useful way to inline Math.max or Math.min in
TurboFan optimized code. This adds new operators NumberMax and NumberMin
and changes the Float64Max/Float64Min operators to have JavaScript
semantics instead of the C++ semantics that it had previously.
This also removes support for recognizing the tenary case in the
CommonOperatorReducer, since that doesn't seem to have any positive
impact (and actually doesn't show up in regular JavaScript, where
people use Math.max/Math.min instead).
Drive-by-fix: Also nuke the unused Float32Max/Float32Min operators.
R=jarin@chromium.org
Review-Url: https://codereview.chromium.org/2170343002
Cr-Commit-Position: refs/heads/master@{#37971}
Typed lowering now produces SpeculativeNumberShiftLeft for JSShiftLeft if the type feedback is kSignedSmall or kSigned32.
BUG=v8:4583
LOG=n
Review-Url: https://codereview.chromium.org/2150553002
Cr-Commit-Position: refs/heads/master@{#37762}
Import fdlibm versions of acos, acosh, asin and asinh, which are more
precise and produce the same result across platforms (we were using
libm versions for asin and acos so far, where both speed and precision
depended on the operating system so far). Introduce appropriate TurboFan
operators for these functions and use them both for inlining and for the
generic builtin.
Also migrate the Math.imul and Math.fround builtins to TurboFan builtins
to ensure that their behavior is always exactly the same as the inlined
TurboFan version (i.e. C++ truncation semantics for double to float
don't necessarily meet the JavaScript semantics).
For completeness, also migrate Math.sign, which can even get some nice
love in TurboFan.
Drive-by-fix: Some alpha-sorting on the Math related functions, and
cleanup the list of Math intrinsics that we have to export via the
native context currently.
BUG=v8:3266,v8:3496,v8:3509,v8:3952,v8:5169,v8:5170,v8:5171,v8:5172
TBR=rossberg@chromium.orgR=franzih@chromium.org
Review-Url: https://codereview.chromium.org/2116753002
Cr-Commit-Position: refs/heads/master@{#37476}
