The upper 32-bits of the FP compare register are undefined in
the float32 case. The compare instruction returns all 1's or
all 0's, so just use the LS bit.
Remove unnecessary use of 'at' reg. Change mips32 for consistency,
but it did not have the bug.
TEST=mjsunit/asm/embenchen/box2d (r6)
BUG=
Review URL: https://codereview.chromium.org/1425603002
Cr-Commit-Position: refs/heads/master@{#31582}
Drive-by-fix: Move IC::GetRootConstructor to Map::GetConstructorFunction,
so we can use that in the ICs, Crankshaft and Turbofan.
R=jarin@chromium.org
BUG=v8:4470
LOG=n
Review URL: https://codereview.chromium.org/1416493007
Cr-Commit-Position: refs/heads/master@{#31577}
Adds support and tests for conditional (ternary) expressions.
BUG=v8:4280
LOG=N
Review URL: https://codereview.chromium.org/1417053004
Cr-Commit-Position: refs/heads/master@{#31575}
Reason for revert:
Causes memory footprint regression: https://code.google.com/p/chromium/issues/detail?id=541135
The intent of the code here was to advance the inline allocation limit without counting the allocated memory towards a step. Calling LowerInlineAllocationLimit this way is a blunt way of doing it, but it works.
At this point it is simplest to revert this CL. My follow-on CL (https://codereview.chromium.org/1404523002/) can address the 'bluntness' of calling LowerInlineAllocationLimit from here along with leaving a comment about the intent.
revert_cq: 1
revert_reason_textarea: Causes memory footprint regression: https://code.google.com/p/chromium/issues/detail?id=541135
The intent of the code here was to advance the inline allocation limit without counting the allocated memory towards a step. Calling LowerInlineAllocationLimit this way is a blunt way of doing it, but it works.
At this point it is simplest to revert this CL. My follow-on CL (https://codereview.chromium.org/1404523002/) can address the 'bluntness' of calling LowerInlineAllocationLimit from here along with leaving a comment about the intent.
Original issue's description:
> [heap] remove unneeded call to LowerInlineAllocationLimit
>
> Calling LowerInlineAllocationLimit from the bottom of Heap::Scavenge seems to be
> a no-op.
>
> new_space_.LowerInlineAllocationLimit(
> new_space_.inline_allocation_limit_step());
>
> LowerInlineAllocatoinLimit does the following things:
>
> 1. Set the inline_allocation_limit_step_ to the passed in value. No-op.
> 2. Calls UpdateInlineAllocationLimit(0). This is unnecessary here as it has
> already been called when new_space_.ResetAllocationInfo was called above.
> 3. Sets top_on_previous_step_. This again is unnecessary as it gets reached by
> ResetAllocationInfo as well.
>
> BUG=
> R=hpayer@chromium.org,ulan@chromium.org
>
> Committed: https://crrev.com/9f8e8b835a468b1622c5350a01a97bc32c5b2fb7
> Cr-Commit-Position: refs/heads/master@{#31156}
TBR=hpayer@chromium.org,ulan@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=chromium:541135
LOG=n
Review URL: https://codereview.chromium.org/1405043005
Cr-Commit-Position: refs/heads/master@{#31574}
Introduce new typing rules for LoadField[Map], which try to take into
account stable map information if the object either has type Constant or
type Class. If the map of the object is stable but can transition we
have to introduce a code dependency in the Typer to make sure that the
information (the Constant type we infer for LoadField[Map]) is valid
(and stays valid).
This also settles the policy for depending on map stability: The
definition can introduce any number of maps, without having to pay
attention to stability (i.e. you can always use Type::Class to introduce
a map that is propagated along the value edges), and the use site is
responsible for checking that the type information is valid before using
it. I.e. if you use stable map information, you'll have to add a
stability dependency (or make sure the map cannot transition).
Drive-by-improvement: Add ReferenceEqualTyper which takes input types
into account for improved constant folding.
Drive-by-fix: Apply policy mentioned above to JSNativeContextSpecialization.
R=jarin@chromium.org, rossberg@chromium.org
BUG=v8:4470
LOG=n
Review URL: https://codereview.chromium.org/1410953006
Cr-Commit-Position: refs/heads/master@{#31567}
From the Google C++ style guide: "You may not use a using-directive to
make all names from a namespace available". This would be covered by
presubmit linter checks if build/namespaces were not blacklisted.
R=bmeurer@chromium.org
Review URL: https://codereview.chromium.org/1410073004
Cr-Commit-Position: refs/heads/master@{#31565}
This fixes the representation type for values in JSArray::length fields
when JSNativeContextSpecialization lowers loads. Only arrays with fast
elements kind are guaranteed to have a Smi represented length.
R=bmeurer@chromium.org
TEST=mjsunit/regress/regress-4515
BUG=v8:4515, v8:4493, v8:4470
LOG=n
Review URL: https://codereview.chromium.org/1410393006
Cr-Commit-Position: refs/heads/master@{#31558}
Currently we (mostly) infer FunctionType for JSFunction constants, and
match the FunctionType in the typing rule for JSCallFunction. This has
several drawbacks for JavaScript, especially we don't have Constant
types for global functions (i.e. String, Object, Reflect and friends).
Plus the FunctionType magic doesn't actually buy us anything. So this
changes the typing rule for HeapConstant constant to actually infer
Constant types for JSFunction objects and moves the recognition of
builtin functions to the typing rule for JSCallFunction.
Also adapts the specialized lowering in JSTypedLowering to Constant
functions instead of FunctionType, which has the additional advantage
that we can do the receiver wrapping/converting based on the (known)
SharedFunctionInfo.
R=jarin@chromium.org
Review URL: https://codereview.chromium.org/1420093005
Cr-Commit-Position: refs/heads/master@{#31553}
The reason is when native_context_specialization flag is ture, X87 turbofan
will hit the known issue that X87 will change a sNaN to qNaN by default. And
then it will fail when bit-comparing the source (sNaN) and the result (qNaN).
reland https://codereview.chromium.org/1414733004/.
BUG=
Review URL: https://codereview.chromium.org/1419573007
Cr-Commit-Position: refs/heads/master@{#31552}
This lowers JSCreateArguments nodes within inline (i.e. non-outermost)
frames that create "unmapped arguments objects" to inline allocations.
The arguments count as well as each value is statically known and can be
directly stored into the arguments object. Note that the object is still
context-dependent and the map is loaded from the current context. The
object size is not taken into account for now, we might want to limit it
later though to keep code size bounded.
R=jarin@chromium.org
Review URL: https://codereview.chromium.org/1412113004
Cr-Commit-Position: refs/heads/master@{#31550}
This addresses an issue where the at-start splitting used
in the splintering mechanism was in conflict with the mechanics
used in linear allocator, in particular in the initial split/spill of
ranges for memory operands. We are already doing a split-at-start in
Greedy, so this change centralizes that to the base RegisterAllocator.
Verified locally that v8:4508 is addressed by this. Also, this fixes
the failures that required the revert
5308a999eb. See trybots at
issue 1425533002.
R=bmeurer@chromium.org,jarin@chromium.org
BUG= v8:4508
LOG=n
Review URL: https://codereview.chromium.org/1426583002
Cr-Commit-Position: refs/heads/master@{#31544}
Reason for revert:
because of merge mistake, "regress/" is missed when skipping one test case for X87.
"regress/" will be added when relanding it.
Original issue's description:
> X87: disable the regress-undefined-nan test case for x87.
>
> The reason is when native_context_specialization flag is ture, X87 turbofan
> will hit the known issue that X87 will change a sNaN to qNaN by default. And
> then it will fail when bit-comparing the source (sNaN) and the result (qNaN).
>
> BUG=
>
> Committed: https://crrev.com/b3c719ebbad6c87afefa33a7d0b3f412b2e304db
> Cr-Commit-Position: refs/heads/master@{#31530}
TBR=bmeurer@chromium.org,weiliang.lin@intel.com
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=
Review URL: https://codereview.chromium.org/1417303005
Cr-Commit-Position: refs/heads/master@{#31543}
port e678a0f9a9 (r31358)
original commit message:
Use %_ToLength for TO_LENGTH, implemented via a ToLengthStub
that supports a fast path for small integers. Everything else is still
handled in the runtime.
BUG=
Review URL: https://codereview.chromium.org/1421803002
Cr-Commit-Position: refs/heads/master@{#31542}
For some reason, the DisableCrankshaft() in ast-numbering.cc does not always
prevent crankshaft from happening. Bailout here rather than asserting an
unreachable condition.
BUG=546967, v8:4488
LOG=N
R=bmeurer@chromium.org
Review URL: https://codereview.chromium.org/1414713004
Cr-Commit-Position: refs/heads/master@{#31537}
