This change build LLILC with CoreCLR's GcInfoEncoding Library.
-> The GcInfoEncoder headers and implementation are available in CoreCLR's
Output directory.
-> include\GcInfoUtil provides (alternate implementations for) some
data-structures and utilities used by the encoder
-> LLILC generates GcInfo correctly using the encoder.
GcInfoUtil provides the following utilities used by the GcInfoEncoder:
1) Logging functions used by the encoder
2) Helpers for bit-manipulation and overflow checking
3) A simple allocator (using new and delete)
4) SList -- a singly linked list that supports insert-at-tail.
This is a subset of SList in CoreCLR tree, with only necessary functionality.
5) CQuickSort - A simple quick sort implementation with comparer
overridden by the GcInfo encoder library -- from the CoreClr tree.
6) StructArrayList -- a list of arrays which has specific growth and location
preserving characteristics -- simplified version from CoreCLR tree.
7) SimplerHashTable -- a wrapper around standard unordered map, with
the encoder's own hashing and comparison functions.
Testing:
All LLILC Unit tests passed locally
Rosly builds without the need for code-size workarounds.
LLVMConfig.cmake (which we use when building out-of-tree) sets
TARGET_TRIPLE instead of LLVM_DEFAULT_TARGET_TRIPLE. Work around this
by setting LLVM_DEFAULT_TARGET_TRIPLE to TARGET_TRIPLE when building
out-of-tree.
When configuring standalone LLILC (i.e. when the LLILC repo
is not placed in LLVM/tools), we were not setting
LLVM_RUNTIME_OUTPUT_INTDIR and LLVM_LIBRARY_OUTPUT_INTDIR.
These must be set if an executable is added.
While testing I also added a dummy (placeholder) driver to verify that
it is compiled and executable created for it. However we will wait to
check in a driver until it is actually functional.
- The PAL definitions we need from CoreCLR moved out of libcoreclr and
into libcoreclrpal. Update CMakeLists accordingly.
- The JIT options sources were inconsistent with the rest of the code
w.r.t. the use of the `this` pointer and were missing copyright
headers.
Remove CLR headers and add dependency on a prebuild CoreCLR. Most of the headers in the
include\clr subdirectory are removed and now are picked up from a prebuilt coreclr so that
keeping in sync is clearer.
Remaining headers are used to support packing in the PAL. Follow on
work will remove these dependencies.
First, we need to remove CACHE from the line to avoid any previously
wrong path name that polluted the cache and cmake might pick it up
from the cache.
Second, the way to pass LLVM Build directory in cmake command line
should be -DWITH_LLVM:STRING=[path to your llvm build directory] not
-DWITH_LLVM=[path to your llvm build directory].
- LLVM recently bumped the required version of CMake to 2.8.12.2, which
contains proper support for private linkage in link_target_library.
This commit removes the workaround that had previously been in place.
- LLVM probing was slightly off for out-of-tree builds.
- Set LLILC_ENABLE_DOXYGEN if LLVM_ENABLE_DOXYGEN is set
- Find Doxygen and Graphviz at configure time when building out-of-tree
or when LLILC_ENABLE_DOXYGEN is set and LLVM_ENABLE_DOXYGEN is not
In more detail:
Modified LLILC's CMakeLists.txt to
1. Add an LLILC_ENABLE_DOXYGEN option (ON by default)
2. configure a Doxygen configuration file.
3. Add a custom target, doxygen-llilc, to run doxygen.
In addition a file, Documentation/index.dox, is added that has the main page
for the LLILC Doxygen output.
To use you need to do the following:
1. Install Doxygen
2. Install Graphviz, ensuring that dot is on your path.
3. In your LLVM source directory, edit the CMakeLists.txt file so that LLVM_ENABLE_DOXYGEN is ON, or alternately when you run cmake give it an option to enable it.
4. After you configure LLVM you can open the LLVM.sln file, right click on doxygen-llilc, and select "build". You do not need to build LLVM before doing this.
- Don't use find_package for LLVM if MSILC_WITH_LLVM is defined
- Probe for libcoreclr.so whether or not we are building from within
the LLVM tree.
- Move the definition for __stdcall outside of an outer _MSC_VER guard.
- Remove MSILCJIT_PATH_TO_LLVM_SOURCE
- Rename MSILCJIT_PATH_TO_{LLVM_BUILD,CORECLR} to MSILC_WITH_{LLVM,CORECLR}
- Improve probing for LLVM and CoreCLR
- Switch ad-hoc discovery of certain LLVM components to definitions from
LLVMConfig.cmake
The backend will fail to emit functions containing FRem instructions
on platforms where fmod is not available at runtime; this currently
includes CoreCLR on Windows (by default, at least).
We may be able to defer this lowering by changing the target library
options for the backend, but this likely requires a change to MCJIT.
Fixes#19.
- libcoreclr need to be passed to the linker when linking libmsilcjit
on Linux in order to avoid undefined symbol errors
- Replace a number of MSVC-specific attributes with their GCC/Clang
equivalents
- Clean up some type/variable naming conflicts
- Migrate MSILCJit to use unique_ptr to track module ownership.
Don't link against libcoreclr on Windows.
Swaroop Sridhar
Matt Mitchell
Pat Gavlin
Richard L. Ford
rhadley
Michelle McDaniel
Bengu Li
dotnet-bot