Merge branch 'master' into EH

Conflicts:
	lib/Jit/LLILCJit.cpp

Documentation/Areas-To-Contribute.md

@@ -0,0 +1,89 @@
+# Areas to Contribute
+
+Below is a list of areas where LLILC needs work.
+Their order follows the path to creating a functioning JIT, that can compile
+most C# programs; and doing so with contributions from the Community - so good
+documentation comes early.
+Each item is given a "star" rating: 1 star denotes easy; many stars denote challenging.
+
+We always keep a [list of open issues](https://github.com/dotnet/llilc/issues)
+in the repo, to track open work items.  This is a good place to start.  But
+beware that it changes day-by-day.  So if you spot an item you'd like to work
+on, assign it to yourself, so everyone can see it's being worked on.
+
+As you work on an issue, it will likely spawn more work.  So enter these as issues.
+
+## Major Areas
+
++ (*) Areas where documentation needs improving.
+  Eg: [#122](https://github.com/dotnet/llilc/issues/122) thru
+      [#176](https://github.com/dotnet/llilc/issues/176)
+
++ (**) Extend the Reader
+  Eg: [#278](https://github.com/dotnet/llilc/issues/278) thru
+      [#286](https://github.com/dotnet/llilc/issues/286) thru
+
++ (**) Add support for more MSIL opcodes.
+  Eg: [#187](https://github.com/dotnet/llilc/issues/187) thru
+      [#192](https://github.com/dotnet/llilc/issues/192)
+
++ (**) Implement missing TODO features.  Eg:
+  + Synchronized methods [#271](https://github.com/dotnet/llilc/issues/271)
+  + Just my code [#272](https://github.com/dotnet/llilc/issues/272)
+  + Explicit class initialization [#274](https://github.com/dotnet/llilc/issues/274)
+  + Union types [#275](https://github.com/dotnet/llilc/issues/275)
+  + Virtual stub dispatch [#267](https://github.com/dotnet/llilc/issues/267)
+  + Intrinsic calls
+
++ (***) Finish support for CoreCLR Generics.
+
++ (****) Exception Handling.
+  Eg: [#63](https://github.com/dotnet/llilc/issues/63) thru
+      [#77](https://github.com/dotnet/llilc/issues/77)
+
++ (**) Memory allocation [#233](https://github.com/dotnet/llilc/issues/233)
+
++ (***) Function inlining [#239](https://github.com/dotnet/llilc/issues/239)
+
++ (*) Enable vectorization (System.Numerics.Vector)
+
++ (**) Add aliasing information for loads that are known to be
+  invariants (eg array length, vtables, etc).
+  [#291](https://github.com/dotnet/llilc/issues/291)
+
++ (**) GC Lifetime Checker.
+  [#34](https://github.com/dotnet/llilc/issues/34)
+
++ (***) Ports to other platforms.
+  +  Linux and MAC OSX are basically working, but need refining
+  +  Other platforms (eg: ARM-64)
+
++ (**) Enable deferred lowering of certain runtime
+  contructs [#292](https://github.com/dotnet/llilc/issues/292)
+  + Helper calls (eg: double->int conversions)
+  + Write barriers
+  + Struct copying
+
+
++ (***)Design & Architecture.
+  Eg: [#22](https://github.com/dotnet/llilc/issues/22); Object-Model Operators;
+
++ (**) Optimizations specific to C#:
+  + null check
+  + bounds check
+  + type check
+  + overflow check
+  + etc
+
++ (*) Add benchmarks for optimization
+
++ (\*\*) Add web-crawler to *harvest* MSIL tests and execute
+
++ (***) Generator for random (but legal) MSIL code [#503](https://github.com/dotnet/llilc/issues/503)
+
++ (**) Bugs
+  +  If you want to fix an existing bug, assign to yourself and go
+  +  If you find a new bug, please check it's not a
+  duplicate, then enter as an issue, with as simple a repro as you can devise
+
++ (**) NGEN support [#287](https://github.com/dotnet/llilc/issues/287)

Documentation/Background.md

@@ -0,0 +1,14 @@
+# Background
+
+LLILC is an Open-Source project that Compiles msIL (.NET) code to native
+binary, using the LLVM compiler framework.  We pronounce it "lilac". The
+project will provide both a JIT ("Just-In-Time") and an AOT ("Ahead-Of-Time")
+compiler targeting [CoreCLR](https://github.com/dotnet/coreclr).  
+
+The LLILC LLVM based toolchain is a companion project to the CoreCLR RyuJIT
+providing the community with an accessible infrastructure for experimentation
+and porting to new targets. Our goal is to make it easy(-ier) to make new
+tools or take C# to new platforms.  Our initial supported platform is Windows
+but we plan to extend support to Linux and Mac in the near term.  
+
+For more background on the .NET Architecture, see its [ECMA Specification](http://www.ecma-international.org/publications/standards/Ecma-335.htm).

Documentation/Code-Formatting.md

@@ -0,0 +1,61 @@
+# Code Formatting
+
+The LLILC project is structured as a subproject of LLVM so we are using the
+same coding conventions as LLVM. See the [coding convention document](llilc-Coding-Conventions-and-Commenting-Style.md)
+for more details.  To maintain these conventions, we require all contributors
+to run our code formatting script over their changes before submitting a pull
+request. The code formatting script is found at LLILC\utils\ccformat.py.
+
+## Prerequisites
+
+* clang-format should be on your path. clang-format can either be installed
+  by downloading Clang's prebuilt binaries from LLVM directly (http://llvm.org/releases/download.html)
+  or building clang from source.
+
+## Checking Formatting
+
+To check the formatting of any submissions, contributors should run from
+their main LLILC enlistment directory:
+
+> utils\ccformat.py
+
+This will run clang-format.exe over all of the LLILC source, and print any
+formatting errors that it found.
+
+If you do not have clang-format on your path, you can specify where the
+script should look for clang-format:
+
+> utils\ccformat.py --clang-format \<full path to clang-format\>
+
+If you do not want to see the diffs, but only want to know if you have
+formatting errors, you can run with --hide-diffs:
+
+> utils\ccformat.py --hide-diffs
+
+## Fixing Formatting errors
+
+If ccformat.py informs you that there are diffs between your code and the
+formatted version returned by clang-format, contributors need to run with
+--fix to automatically fix formatting errors:
+
+> utils\ccformat.py --fix
+
+## Running clang-tidy
+
+Currently, we do not run clang-tidy by default with ccformat.py. If a
+contributor would like to run clang-tidy, he can run ccformat.py with --tidy:
+
+> utils\ccformat.py --tidy
+
+There are various options contributors can pass to clang-tidy which can be
+seen by running:
+
+> utils\ccformat.py --help
+
+## Running ccformat without clang-format
+
+Contributors may choose to run ccformat.py without running clang-format
+(when running tidy, for example). To do so, run ccformat.py with the
+--noformat switch:
+
+> utils\ccformat.py --noformat

Documentation/Contributing.md

@@ -0,0 +1,36 @@
+# Contribution Guide
+
+## Workflow
+We follow the standard [GitHub workflow](https://guides.github.com/introduction/flow/).
+We like to track ongoing work using GitHub issues as described in the
+[developer workflow document](Developer-Workflow.md).
+ - To submit changes, please create a personal fork of the LLILC repo, push
+   your changes there, and issue a pull request to merge those changes into
+   the master branch of the main repository.
+ - Please be sure to perform the appropriate [formatting](#coding-conventions-and-formatting)
+   and [testing](#testing) as described below before submitting your pull
+   request.
+ - Whenever possible, please divide any changes you want to make into a
+   series of small, incremental changes that can be submitted and reviewed
+   independently.  Doing so will
+    - Make the code easier to review (allowing for higher quality review
+      feedback)
+    - Keep your work aligned with LLILC's direction and architecture along
+      the way (avoiding wasted time pursuing a direction that ultimately
+      gets abandoned)
+    - Spare you the pain of keeping large outstanding changes up-to-date
+      with tip-of-tree
+ - Occasionally we'll deviate from this model and use long-lived branches,
+   which follow [another workflow](Long-Running-Branch-Workflow.md).
+
+## Coding Conventions and Formatting
+Any code being submitted must be formatted per the instructions in the
+[code formatting document](Code-Formatting.md).  We follow LLVM's coding
+conventions, as described in our [coding conventions document](llilc-Coding-Conventions-and-Commenting-Style.md).
+
+## Testing
+The [test harness document](Testing.md) describes the tests we expect to be
+run for each submission and how to run them.
+
+## Open Areas
+Looking for an area to contribute to?  See our [list of open areas](Areas-To-Contribute.md).

Documentation/Developer-Workflow.md

@@ -0,0 +1,84 @@
+# Developer Workflow
+
+## Introduction
+
+This documents our typical workflow. At a high level this covers how we
+expect issues to work, what our development cadence is, and how we do design
+for larger features.  And by we, we mean the whole community. These guidelines
+hopefully foster collaboration and high quality, useful software.
+(Some fun wouldn't hurt either.)
+
+## Issues
+
+We use GitHub issues to track work, so if you're working on something, open
+an issue.  It gives the community a place to have a conversation about the
+fix/feature that's being worked on.  In addition it helps everybody keep
+track of who is working on what so that we can minimize duplication and
+redundant work.
+
+The typical issue flow is as follows:
+- Have a great idea, or find a bug, and open issue.
+- Issue is discussed on GitHub and a direction is established.
+- Somebody signs up to do the work and potentially a sprint milestone is
+  assigned if the work directly effects a particular near term project
+  [goal](https://github.com/dotnet/llilc/blob/master/Documentation/llilc-milestones.md).
+- Ongoing notes on the implementation are added to the issue as work progresses.
+- Work is completed, tested, PR'd, and merged in.
+- Issue is closed
+
+Note on 'assigning' issues: The only people that can be assigned to an issue
+in GitHub are people that are in one of the project groups (either *llilc* -
+read/write access, or *llilc-community* - read only access).  We add people
+to the Community group after their first PR is accepted by the collaborators.
+This enables you to be added as the assignee for issues.  So if this is your
+first issue, note your Github account name in the issue as the person
+working on it and others will understand that it's in flight.
+
+Note on read/write access: We'd like to develop a broad set of committers to
+the project from the community (we don't have any non-MS committers at this
+point) we think that this should happen after people build a track record in
+the llilc-community group.  The expectation is that after few (3-5) non-trivial
+contributions a community member can request to be added to the project group
+and gain read/write access to the source.  With this access also comes the
+expectation that the collaborator will help review others PR's, help maintain
+documentation, as well as generally facilitate the smooth running of the project.
+
+## Workflow
+
+We use 3 week sprints in a agile(-ish) model.  These sprints are added as
+Milestones in Github (not to be confused with the project [Milestones](llilc-milestones.md)
+which are larger granularity proof points of functionality.)  Look at the
+[Github milestones page](https://github.com/dotnet/llilc/milestones) to see
+the individual sprints and their end dates. These sprints are used by core
+members of the team to managed work toward near term goals, but it is not
+necessary for community contributors to use these milestones.  The only place
+where this could potentially cause some complication is if a particular
+feature/fix is needed for a near term goal.  In this case we would have a
+conversation about assigning the issue to a milestone and potentially moving
+the work to a collaborator that can commit to a solution in the needed time
+frame. We're attempting to have a balance between an open and friendly
+environment to hack and the necessity to drive functionality (as well as
+  meet product goals).
+
+A typical flow is as follows:
+- Day one of a sprint milestone work is self-assigned by developers based on
+  a combination of priority and what the think that they can get done in a 3
+  week period.
+- Through out the sprint notes are added to the issues assigned to the sprint
+  outlining progress.
+- Issues are closed as they are merged back in and the CI system stays green.
+- On the first day of the next sprint, any items not completed are triaged
+  and moved to the appropriate sprint. (Typically this is the next sprint)
+
+## Design process
+
+As stated above, all features start as issues.  If as part of the conversation
+about an issue, the community decides that a particular feature is large or
+complicated enough to warrant a separate write up a document will be created
+by interested parties describing the design and the staging of bring up.
+This document will be reviewed via PR and checked in as separate markdown in
+the project Documentation directory off the root.  A good example of this is
+the [EH design document](llilc-jit-eh.md). As you can see today only larger,
+more complicated areas warrant this treatment.  I want to highlight that
+typical work will be handled via issues, reserving this process for areas
+that require months of development to bring to fruition.

Documentation/Getting-Started-For-Linux-and-OS-X.md

@@ -0,0 +1,72 @@
+# Getting Started for Linux and OS X
+
+## Caveats
+
+Support for LLILC on Linux and OS X is still in its early stages. While the
+instructions below should get you up and running, the workflow is a bit rough
+around the edges and there are certainly holes with respect to what is
+supported. The most obvious missing piece is that without following the steps
+on the [CoreCLR wiki](https://github.com/dotnet/coreclr/wiki/Building-and-Running-CoreCLR-on-Linux)
+to obtain a version of mscorlib that is functional on these platforms, there
+is no way to run or test the output of the LLILC build.
+
+## Prerequisites
+
+The prerequisites for building LLILC on Linux and OS X are the same as the
+[prerequisites for building LLVM](http://llvm.org/docs/GettingStarted.html#software)
+with CMake unioned with the prerequisites for building [CoreCLR](https://github.com/dotnet/coreclr).
+
+* [GCC](http://gcc.gnu.org) >= 4.7.0
+* [Clang](http://clang.llvm.org/) >= 3.5.0
+* [Python](http://python.org) >= 2.7
+* [CMake](http://cmake.org) >= 2.8.8
+* [libunwind](http://www.nongnu.org/libunwind/) >= 1.1
+
+In addition, LLILC requires very recent builds of the [Microsoft fork of LLVM](https://github.com/microsoft/llvm)
+and [CoreCLR](https://github.com/dotnet/coreclr). Instructions for fetching
+and building both can be found below.
+
+## Getting and building the code
+
+1. Clone and build CoreCLR:
+
+    ```
+    $ git clone https://github.com/dotnet/coreclr
+    $ cd coreclr
+    $ ./build.sh
+    $ cd ..
+    ```
+
+    After it completes, the build will indicate where the CoreCLR binaries
+    are available. Make a note of this location
+    (typically binaries/Product/<os>.x64.debug).
+
+2. Clone the Microsoft fork of LLVM:
+
+    ```
+    $ git clone -b MS https://github.com/microsoft/llvm
+    ```
+
+3. Clone LLILC:
+
+    ```
+    $ cd llvm/tools
+    $ git clone https://github.com/dotnet/llilc
+    $ cd ..
+    ```
+
+4. Configure LLVM and LLILC:
+
+    ```
+    $ mkdir build
+    $ cd build
+    $ cmake -DWITH_CORECLR=../../coreclr/path/to/CoreCLR/binaries ..
+    ```
+
+5. Build LLVM and LLILC:
+
+    ```
+    $ make
+    ```
+
+    If all goes well, the build will complete without errors.