Ice::Inst::NumberSentinel is defined within the Inst class definition:

class Inst {
  ...
  static const InstNumberT NumberDeleted = -1;
  static const InstNumberT NumberSentinel = 0;
  ...
};

Under some compilers/options, this causes a link error when passing NumberSentinel as a const T& argument.

(Another option would be to move the actual definitions into IceInst.cpp.)

BUG= none
R=jfb@chromium.org

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

Includes the following:
1. Liveness analysis.
2. Linear-scan register allocation.
3. Address mode optimization.
4. Compare-branch fusing.

All of these depend on liveness analysis.  There are three versions of liveness analysis (in order of increasing cost):
1. Lightweight.  This computes last-uses for variables local to a single basic block.
2. Full.  This computes last-uses for all variables based on global dataflow analysis.
3. Full live ranges.  This computes all last-uses, plus calculates the live range intervals in terms of instruction numbers.  (The live ranges are needed for register allocation.)

For testing the full live range computation, Cfg::validateLiveness() checks every Variable of every Inst and verifies that the current Inst is contained within the Variable's live range.

The cross tests are run with O2 in addition to Om1.

Some of the lit tests (for what good they do) are updated with O2 code sequences.

BUG= none
R=jvoung@chromium.org

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

BUG= none
R=stichnot@chromium.org

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

1. Comma-terminated enumerator lists.
2. Empty macro arguments.
3. Variable-length arrays.

The first issue is definitely hitting the Mac bots.  The other two issues will quite possibly following that.

BUG= none
R=jfb@chromium.org

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

Previously, the basis of constant pooling was implemented, but two things were lacking:

1. The constant pools were not being emitted in the asm file.

2. A direct FP value was emitted in an FP instruction, e.g. "addss xmm0, 1.0000e00".  Curiously, at least for some FP constants, llvm-mc was accepting this syntax.

BUG= none
R=jfb@chromium.org

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

This change now supports building subzero as part of the LLVM build (instead
of in a separate build step). It is modeled on clang's Makefiles.

The existing Makefile has been renamed and can still be used manually, e.g.
Make -f Makefile.standalone

It does not yet support running tests, just building.

R=stichnot@chromium.org, jvoung@chromium.org
BUG=

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

This adds infrastructure for low-level x86-32 instructions, and the target lowering patterns.

Practically no optimizations are performed.  Optimizations to be introduced later include liveness analysis, dead-code elimination, global linear-scan register allocation, linear-scan based stack slot coalescing, and compare/branch fusing.  One optimization that is present is simple coalescing of stack slots for variables that are only live within a single basic block.

There are also some fairly comprehensive cross tests.  This testing infrastructure translates bitcode using both Subzero and llc, and a testing harness calls both versions with a variety of "interesting" inputs and compares the results.  Specifically, Arithmetic, Icmp, Fcmp, and Cast instructions are tested this way, across all PNaCl primitive types.

BUG=
R=jvoung@chromium.org

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

BUG=None
R=jfb@chromium.org, stichnot@chromium.org

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

This includes just enough code to build the high-level ICE IR and dump it back out again.  There is a script szdiff.py that does a fuzzy diff of the input and output for verification.  See the comment in szdiff.py for a description of the fuzziness.

Building llvm2ice requires LLVM headers, libs, and tools (e.g. FileCheck) to be present.  These default to something like llvm_i686_linux_work/Release+Asserts/ based on the checked-out and built pnacl-llvm code; I'll try to figure out how to more automatically detect the build configuration.

"make check" runs the lit tests.

This CL has under 2000 lines of "interesting" Ice*.{h,cpp} code, plus 600 lines of llvm2ice.cpp driver code, and the rest is tests.

Here is the high-level mapping of source files to functionality:

IceDefs.h, IceTypes.h, IceTypes.cpp:
Commonly used types and utilities.

IceCfg.h, IceCfg.cpp:
Operations at the function level.

IceCfgNode.h, IceCfgNode.cpp:
Operations on basic blocks (nodes).

IceInst.h, IceInst.cpp:
Operations on instructions.

IceOperand.h, IceOperand.cpp:
Operations on operands, such as stack locations, physical registers, and constants.

BUG= none
R=jfb@chromium.org

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

BUG= none
R=jfb@chromium.org

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