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}
Just give internal ones an ArrayBuffer with a NULL backing store. This
simplifies the access checks a lot.
BUG=v8:3996
R=hpayer@chromium.org,verwaest@chromium.org
LOG=n
Review URL: https://codereview.chromium.org/1109353003
Cr-Commit-Position: refs/heads/master@{#28168}
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
Review URL: https://codereview.chromium.org/1100993003
Cr-Commit-Position: refs/heads/master@{#28164}
An initial 'code age' state that will turn into a 'pre-aging' code age only after it was executed the first time.
BUG=470930
LOG=Y
Review URL: https://codereview.chromium.org/1107233004
Cr-Commit-Position: refs/heads/master@{#28162}
