Introduce the ability to insert IACA (Intel Architecture Code Analyzer) marks to

Introduce the ability to insert IACA (Intel Architecture Code Analyzer) marks.

The IACI marks identify the code which should be analyzed with the IACA.

The generated binaries are not executable due to the marks. This feature should
only be used during develpoment when analyzing generated code so it is protected
behind the --allow-iaca-marks flag.

ScopedIacaMark is a helper class which opens mark and closes it at the end of
the scope. This is useful when there are many returns as you don't have to write
`_iaca_end()` before them all.

BUG=
R=stichnot@chromium.org

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

[ascull, 2015-08-05 00:34:26]

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

[Jim Stichnoth, 2015-08-05 05:08:19]

Also, please edit the Subject and first line of the description to be 80 chars
or less.

https://codereview.chromium.org/1260093003/diff/1/src/IceInstX86BaseImpl.h
File src/IceInstX86BaseImpl.h (right):

https://codereview.chromium.org/1260093003/diff/1/src/IceInstX86BaseImpl.h#ne...
src/IceInstX86BaseImpl.h:373:
assert(Func->getContext()->getFlags().getAllowIacaMarks());
This is cool (I now learned about IACA), however, without a concrete example,
it's not clear how this is intended to be used long-term.

Based on this assert, my guess is that some lowering code would add iaca_start
and iaca_end if getAllowIacaMarks() is true.

Would it be easier for _iaca_start() and _iaca_end() to conditionally insert the
corresponding instruction based on the flag?  If so, then this assert may be
unnecessary? (though harmless I guess)

We probably also want to make sure none of this code is used in a MINIMAL build.

[ascull, 2015-08-05 18:10:34]

https://codereview.chromium.org/1260093003/diff/1/src/IceInstX86BaseImpl.h
File src/IceInstX86BaseImpl.h (right):

https://codereview.chromium.org/1260093003/diff/1/src/IceInstX86BaseImpl.h#ne...
src/IceInstX86BaseImpl.h:373:
assert(Func->getContext()->getFlags().getAllowIacaMarks());
On 2015/08/05 05:08:19, stichnot wrote:
> This is cool (I now learned about IACA), however, without a concrete example,
> it's not clear how this is intended to be used long-term.
> 
> Based on this assert, my guess is that some lowering code would add iaca_start
> and iaca_end if getAllowIacaMarks() is true.
> 
> Would it be easier for _iaca_start() and _iaca_end() to conditionally insert
the
> corresponding instruction based on the flag?  If so, then this assert may be
> unnecessary? (though harmless I guess)
> 
> We probably also want to make sure none of this code is used in a MINIMAL
build.

When you run IACA, it analyzes all the marks in the executable. It
reports them as marks 1, 2, 3... which is just the order that they
appear in the executable. This makes it quite difficult to manage the
results if you have a lot of marks in different places. For this reason
I don't think leaving the marks around and activating them with the
flag would be very effective.

Instead I imagine this being used for a before and after comparison or
to help evaluate different strategies by manually inserting the marks
as you are focusing on a particular area. Also, being used with
lowerInst at a position could be useful for seeing if code transforms
have a benefit.

I have found myself asking 'is it better to use sequence of
instructions x, or sequence y?' and this could provide some sort of an
answer.

Speaking with Jan, he imagined using IACA to look for differences
between subzero and LLVM. Unfortunately this would require knowledge of
the kernel you wish to focus on rather than just analyzing the whole
program. This limitation is due to IACA which only works well with a
linear sequence of instructions as it is a static analysis. The
throughput of loops can be analyzed but that requires knowledge of the
loops which is lost in the IR.

I thought about using an LLVM intrinsic to insert the marks externally
but Jan says this might be quite painful to get working, particularly
if it also needs to be added to LLVM in order to make comparisons.

I have a test for minimal in _iaca_*() but have left this assert as a
safety net (as well as the reason in the first <p>).

[Jim Stichnoth, 2015-08-06 13:33:24]

Thanks, lgtm.

[ascull, 2015-08-06 15:41:57]

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