[turbofan] extend register allocator testing with control flow

R=bmeurer@chromium.org, jarin@chromium.org

BUG=

Review URL: https://codereview.chromium.org/699083003

Cr-Commit-Position: refs/heads/master@{#25178}
git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@25178 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Retry: Parser & internalization fix: ensure no heap allocs during GetString(Handle<String>).

The bug has always been there: when the parser is operating in the "immediately
internalize" mode and calls GetString, we get FlatContent of a string and then
do heap allocation.

The bug was uncovered by https://codereview.chromium.org/693803004/ (which put
the parser to the "immediately internalize" mode more often), but looking at the
code, it's possible that it can happen in other cases too.

This CL makes AstValueFactory handle this situation gracefully: it won't try to
internalize inside GetString(Handle<String>); it's unnecessary anyway since we
have the Handle<String> already.

BUG=
R=rossberg@chromium.org

Review URL: https://codereview.chromium.org/706533005

Cr-Commit-Position: refs/heads/master@{#25179}
git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@25179 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
[turbofan] Turn various diamonds into selects.

TEST=cctest/test-changes-lowering,mjsunit/asm,unittests
R=jarin@chromium.org

Review URL: https://codereview.chromium.org/704463004

Cr-Commit-Position: refs/heads/master@{#25180}
git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@25180 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Avoid redundant work in scheduler loop header/depth calculation.

R=jarin@chromium.org

TEST=cctest/test-scheduler/LoopedFloatingDiamond2

Review URL: https://codereview.chromium.org/702683002

Cr-Commit-Position: refs/heads/master@{#25181}
git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@25181 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
The idea behind of this solution is to use the existing "relocation info" instead of consumption the CodeLinePosition events emitted by the V8 compilers.
During generation code and relocation info are generated simultaneously.
When code generation is done you each code object has associated "relocation info".
Relocation information lets V8 to mark interesting places in the generated code: the pointers that might need to be relocated (after garbage collection),
correspondences between the machine program counter and source locations for stack walking.

This patch:
1. Add more source positions info in reloc info to make it suitable for source level mapping.
The amount of data should not be increased dramatically because (1) V8 already marks interesting places in the generated code and
(2) V8 does not write redundant information (it writes a pair (pc_offset, pos) only if pos is changed and skips other).
I measured it on Octane benchmark - for unoptimized code the number of source positions may achieve 2x ('lin_solve' from NavierStokes benchmark).

2. When a sample happens, CPU profiler finds a code object by pc, then use its reloc info to match the sample to a source line.
If a source line is found that hit counter is increased by one for this line.

3. Add a new public V8 API to get the hit source lines by CDT CPU profiler.
Note that it's expected a minor patch in Blink to pack the source level info in JSON to be shown.

4.Add a test that checks how the samples are distributed through source lines.
It tests two cases: (1) relocation info created during code generation and (2) relocation info associated with precompiled function's version.

Patch from Denis Pravdin <denis.pravdin@intel.com>;

R=svenpanne@chromium.org, yurys@chromium.org

Review URL: https://codereview.chromium.org/682143003

Patch from Weiliang <weiliang.lin@intel.com>.

Cr-Commit-Position: refs/heads/master@{#25182}
git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@25182 ce2b1a6d-e550-0410-aec6-3dcde31c8c00