Subzero: Fix labels for block profiling.

Subzero: Fix labels for block profiling.

The problem is that the block profiling pass runs at the very beginning and commits to particular label strings, but the actual label names might change by emission time because of node reordering.

There was actually something of a workaround - given a label string from the profile output, inspect the *profiled* asm code and search for the block containing the increment of the counter location, as the name of the counter location label is related to the label string in the profile output.  However, it's tedious to mentally filter out the counter update code, and the counter update code has a huge impact on register allocation.

The solution is to use a persistent number in CfgNode for constructing the label string, which doesn't change when the nodes are reordered.

One note (independent of this change): Without block profiling, empty basic blocks are deleted and don't appear in the asm output.  But with block profiling, these blocks are never empty because they contain profile update instructions.  This means the profile output may contain labels that don't exist in the non-profiled asm.

Another note: New nodes created as a result of edge splitting from advanced phi lowering are not profiled.

BUG= none
R=ascull@google.com, jpp@chromium.org

Committed: https://gerrit.chromium.org/gerrit/gitweb?p=native_client/pnacl-subzero.git;a=commit;h=e7dbc0bcab159a2c64d7d8dff746d273bf80fa36

[Jim Stichnoth, 2015-09-12 17:43:33]

stichnot@chromium.org changed reviewers:
+ ascull@google.com, jpp@chromium.org

[John, 2015-09-14 15:06:51]

lgtm

[ascull, 2015-09-14 16:35:37]

It might be useful to leave a TODO somewhere with the notes you put here about
the limitations of block profiling.

https://codereview.chromium.org/1341613002/diff/1/src/IceCfgNode.cpp
File src/IceCfgNode.cpp (right):

https://codereview.chromium.org/1341613002/diff/1/src/IceCfgNode.cpp#newcode30
src/IceCfgNode.cpp:30: : Func(Func), Number(LabelNumber),
LabelNumber(LabelNumber) {}
This assumes no node will be added after a node is removed (from Cfg::makeNode).
I don't think that happens at the moment but is it a safe assumption? Does phi
splitting do this?

[Jim Stichnoth, 2015-09-15 05:24:03]

On 2015/09/14 16:35:37, ascull wrote:
> It might be useful to leave a TODO somewhere with the notes you put here about
> the limitations of block profiling.

Good idea, added.

[Jim Stichnoth, 2015-09-15 05:24:09]

https://codereview.chromium.org/1341613002/diff/1/src/IceCfgNode.cpp
File src/IceCfgNode.cpp (right):

https://codereview.chromium.org/1341613002/diff/1/src/IceCfgNode.cpp#newcode30
src/IceCfgNode.cpp:30: : Func(Func), Number(LabelNumber),
LabelNumber(LabelNumber) {}
On 2015/09/14 16:35:37, ascull wrote:
> This assumes no node will be added after a node is removed (from
Cfg::makeNode).
> I don't think that happens at the moment but is it a safe assumption? Does phi
> splitting do this?

There was an implicit assumption that nodes are only added, never deleted, from
the node list.  I made that more explicit in Cfg::swapNodes().

[ascull, 2015-09-15 16:07:16]

lgtm

[Jim Stichnoth, 2015-09-15 17:09:28]

Committed patchset #2 (id:20001) manually as
e7dbc0bcab159a2c64d7d8dff746d273bf80fa36 (presubmit successful).