Tail calls are matched on the graph, with a dedicated tail call
optimization that is actually testable. The instruction selection can
still fall back to a regular if the platform constraints don't allow to
emit a tail call (i.e. the return locations of caller and callee differ
or the callee takes non-register parameters, which is a restriction that
will be removed in the future).
Also explicitly limit tail call optimization to stubs for now and drop
the global flag.
BUG=v8:4076
LOG=n
Review URL: https://codereview.chromium.org/1114163005
Cr-Commit-Position: refs/heads/master@{#28219}
By recording invocations of these builtins that can return -0, we now learn to not emit Crankshaft code that only handles integer results, avoiding deopt loops.
Review URL: https://codereview.chromium.org/1053143005
Cr-Commit-Position: refs/heads/master@{#28215}
These macros are not needed anymore, so there's no point in supporting
them.
Review URL: https://codereview.chromium.org/1123723003
Cr-Commit-Position: refs/heads/master@{#28214}
When we preprocess stack traces, we turn code pointer and offset to
source position, and store it in place of code pointer as smi.
Preprocessing stack traces is currently disabled due to issue 4065.
R=jkummerow@chromium.org
Review URL: https://codereview.chromium.org/1125723002
Cr-Commit-Position: refs/heads/master@{#28213}
Tick event processor should not stay in a tight loop
when there's nothing to do. It can go sleep until next sample event.
LOG=N
BUG=v8:3967
Review URL: https://codereview.chromium.org/1118533003
Cr-Commit-Position: refs/heads/master@{#28211}
This test fails on board, temporarily skip failing test until we resolve this issue.
NOTRY=true
Review URL: https://codereview.chromium.org/1127573002
Cr-Commit-Position: refs/heads/master@{#28201}
usage: This tool analyzes the commit range between <of> and <until>. It finds commits which belong together e.g. Implement/Revert pairs and Implement/Port/Revert triples. All supplied hashes need to be from the same branch e.g. master.
Example for M42: ./search_related_commits.py --prettyprint --separator e0110920d6b856e87859b1c2a34956
BUG=
NOTRY=true
Review URL: https://codereview.chromium.org/1098123002
Cr-Commit-Position: refs/heads/master@{#28197}
This introduces a simplified allocation operator which can be used to
model inline allocations in TurboFan. It is currently used for context
allocations, but still disabled because change lowering introduces
floating allocations outside the effect chain that interfere.
R=bmeurer@chromium.org
Review URL: https://codereview.chromium.org/1109773002
Cr-Commit-Position: refs/heads/master@{#28195}
These instructions have unpredictable result when the processor is in fp32 mode.
BUG=
TEST=mjsunit/math-floor-global,math-floor-local,math-floor-part1
Review URL: https://codereview.chromium.org/1116073002
Cr-Commit-Position: refs/heads/master@{#28194}
port 83a0af5500 (r28165).
original commit message:
VectorICs: built-in function apply should use an IC.
Handled a TODO that sent builtin function apply to the runtime on property get.
BUG=
Review URL: https://codereview.chromium.org/1119263002
Cr-Commit-Position: refs/heads/master@{#28189}
Reason for revert:
[Sheriff] Speculative revert. This seems to block the current roll:
https://codereview.chromium.org/1124463003/
This bisect also points at this CL:
https://codereview.chromium.org/1124523002/
Please prepare the chromium side tests before a reland.
Original issue's description:
> [V8] Use previous token location as EOS token location
>
> EOS token location is useless for users and messages.js are not ready for its location.
> With this CL we use location of token before EOS for it.
>
> LOG=Y
> BUG=chromium:480652
> R=yurys@chromium.org,yangguo@chromium.org
>
> Committed: https://crrev.com/81afc9313ce84350bcba9f84b255a77e97cd3726
> Cr-Commit-Position: refs/heads/master@{#28164}
TBR=yangguo@chromium.org,yurys@chromium.org,kozyatinskiy@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=chromium:480652
Review URL: https://codereview.chromium.org/1116233004
Cr-Commit-Position: refs/heads/master@{#28187}
- all RegisterAllocatorTest unit tests passing, when unittest has the flags: --turbo-filter=* --always-opt --turbo-deoptimization --turbo-verify-allocation --turbo_greedy_regalloc
./tools/run-tests.py passing when providing --turbo_greedy_regalloc, but still having some failing (more than the "normal" 43) when passing all the flags. I realize just passing --turbo_greedy_regalloc does not provide full coverage, but it did uncover some bugs, still
The CL centralizes the computing of split points (for "losing" intervals) with the determination of whether an interval is irreducible, and, therefore, of infinite spill weight (if an interval can't be split or spilled, it can't lose in weight comparison because there's nothing we can do to it and make progress).
There are allocator efficiency opportunities I haven't yet taken (this refers to the code itself, not the generated code). For example, the above split/spill computation can be cached. My plan is to defer this to at least after we see numbers showing the value of the algorithm, and potentially do at the same time we remove the linear algorithm, if that is still the plan. At that time, we can look where some APIs best belong (e.g. weight computation may fully live and cache itself on LiveRange)
In addition, the CL adds a few debug-time-only Print APIs I found very useful: on demand (while in GDB) dump of the code, live range info (use positions & operand description, and intervals), etc.
BUG=
Review URL: https://codereview.chromium.org/1105793002
Cr-Commit-Position: refs/heads/master@{#28185}
