In the current CoreCLR/CoreFX drops, tests that write to the console will require the jit to generate code that can handle exceptions, unless the current code page is 65001 (my cmd shell defaults to CP 437).

In particular we see a throw from a protected block in System.Text.Encoding.GetEncoding(int32 codePage) with a local catch.

Given that MSILC won't be in a position to generate correct code for catches for a while, we need a workaround -- either set the code page when running the tests, avoid tests that write to the console, get CoreFx to look at whether this behavior is reasonable, or blacklist that method in our jit and allow the production jit to handle it.

Reader conservatively uses single predecessor to reuse the cached shared statics.
More precice one can be implemented.

The CoreCLR has some library code for encoding GC info. We need to add this to our project.

Value type GC fields need reporting, but don't naturally fit into SSA. Find a way to report them.

Our GC reporting requires us to distinguish object pointers from interior pointers. We are using address spaces to track all reportable pointers, but we need some extra mechanism to determine which of these are object pointers and which are interior pointers.

If we insert statepoints fairly early, it might be nice to have a later checking phase that verifies that the GC reporting remains accurate.

For portability move to a fixed size types across all the source.

This should not at this point change the headers we're importing from the CLR. The effort to make those more xplat friendly will need to be separate.

Need to handle the *.ovf family of arithmetic instrructions.
Expand with explicit checks, following the pattern of #63.
If this needs to be two operations in LLVM IR (check for ovf conditions followed by actual arithmetic), make sure to use the .nuw/.nsw form after the check.

Part of #13.

LLILC arch overview
Road map
Fully functional JIT challenges.

Update current boiler plate.

Need overview doc outlining problem space, planned direction, and current status, to give some structure to #13.

We already have a requirement to have python for the LLVM xplat testing. Let's port the format script to python so it can be run anywhere.

We get a lot of raw addresses from the EE for things like methods and static fields. For instance:

%1 = call %System.Text.Encoding addrspace(1)* inttoptr (i64 140733439908056 to %System.Text.Encoding addrspace(1)* (i32)*)(i32 %0)

They make the IR dumps somewhat cryptic. Also these addresses vary from run to run so we have to strip them out when we diff the dumps. Sure would be nice to have names here instead of numbers, like so:

%1 = call %System.Text.Encoding addrspace(1)*System.Text.Encoding::GetEncoding(i32 %0)

Sweep the ported reader code for any calls that are not reference (can log what the linkers /opt:ref removes for the list) and remove them. Any calls that we will start using in the immediate future can be left.

This includes the following msil instructions: conv.ovf.i1, conv.ovf.u1, conv.ovf.i1.un, conv.ovf.u1.un, conv.ovf.i2, conv.ovf.u2, conv.ovf.i2.un, conv.ovf.u2.un, conv.ovf.i4, conv.ovf.u4, conv.ovf.i4.un, conv.ovf.u4.un, conv.ovf.i8, conv.ovf.u8, conv.ovf.i8.un, conv.ovf.u8.un, conv.ovf.i, conv.ovf.u, conv.ovf.i.un, conv.ovf.u.un.

Need to generate an appropriate landingpad for each catch-protected region.
Need to update call generation to generate invoke with edge to landingpad as well.

Part of #13.

For the initial GC bring up, we need to set up all our testing (and user docs) to enable the GC's conservative mode. We should then verify that the current simple GC Info we report is sufficient for this mode, and add tests we can pass where GC happens when there is LLILC compiled code on the stack.

Note: this is a much larger task than for the other handler types, because it requires outlining the filter function.

Part of #13.

This includes ldftn, ldvirtftn and calli msil instructions.

The CoreCLR GC requires that pinned pointers be reported specially.

Funclet outlining should take care of inserting a standard prolog/epilog. However, we'll need to look at how the frame closure is found and make sure that the Previous Stack Pointer Symbol handshake with the runtime is respected.

Part of #13.

Once catch handlers are implemented (#66), we'll need to be able to process rethrow. This should be a straightforward invoke of the rethrow helper.

Part of #13.

The Statepoint work will produce LLVM stack maps at each safepoint. We need to translate this information into the format needed by the GC info encoder.

We are getting the following build errors in staticcontract.h and reader.h during win32 debug build:

D:\j\workspace\dotnet_llvm-msilc_windows_debug_win32_prtest\LLVM\tools\llvm-msilc\include\clr\staticcontract.h(326): error C2061: syntax error : identifier 'UINT' (D:\j\workspace\dotnet_llvm-msilc_windows_debug_win32_prtest\LLVM\tools\llvm-msilc\lib\Reader\GenIRStubs.cpp) [d:\j\workspace\dotnet_llvm-msilc_windows_debug_win32_prtest\build_debug_win32\tools\llvm-msilc\lib\Reader\msilcReader.vcxproj]
D:\j\workspace\dotnet_llvm-msilc_windows_debug_win32_prtest\LLVM\tools\llvm-msilc\include\clr\staticcontract.h(326): error C2061: syntax error : identifier 'UINT' (D:\j\workspace\dotnet_llvm-msilc_windows_debug_win32_prtest\LLVM\tools\llvm-msilc\lib\Reader\reader.cpp) [d:\j\workspace\dotnet_llvm-msilc_windows_debug_win32_prtest\build_debug_win32\tools\llvm-msilc\lib\Reader\msilcReader.vcxproj]
D:\j\workspace\dotnet_llvm-msilc_windows_debug_win32_prtest\LLVM\tools\llvm-msilc\include\clr\staticcontract.h(350): error C2992: 'BlockMarker' : invalid or missing template parameter list (D:\j\workspace\dotnet_llvm-msilc_windows_debug_win32_prtest\LLVM\tools\llvm-msilc\lib\Reader\GenIRStubs.cpp) [d:\j\workspace\dotnet_llvm-msilc_windows_debug_win32_prtest\build_debug_win32\tools\llvm-msilc\lib\Reader\msilcReader.vcxproj]
D:\j\workspace\dotnet_llvm-msilc_windows_debug_win32_prtest\LLVM\tools\llvm-msilc\include\clr\staticcontract.h(350): error C2992: 'BlockMarker' : invalid or missing template parameter list (D:\j\workspace\dotnet_llvm-msilc_windows_debug_win32_prtest\LLVM\tools\llvm-msilc\lib\Reader\reader.cpp) [d:\j\workspace\dotnet_llvm-msilc_windows_debug_win32_prtest\build_debug_win32\tools\llvm-msilc\lib\Reader\msilcReader.vcxproj]
D:\j\workspace\dotnet_llvm-msilc_windows_debug_win32_prtest\LLVM\tools\llvm-msilc\lib\Reader\reader.cpp(6565): error C2079: '__marker_onlyOneAllowedPerScope' uses undefined class 'BlockMarker' [d:\j\workspace\dotnet_llvm-msilc_windows_debug_win32_prtest\build_debug_win32\tools\llvm-msilc\lib\Reader\msilcReader.vcxproj]
D:\j\workspace\dotnet_llvm-msilc_windows_debug_win32_prtest\LLVM\tools\llvm-msilc\lib\Reader\reader.cpp(6565): error C2228: left of '.markBlock' must have class/struct/union [d:\j\workspace\dotnet_llvm-msilc_windows_debug_win32_prtest\build_debug_win32\tools\llvm-msilc\lib\Reader\msilcReader.vcxproj]
D:\j\workspace\dotnet_llvm-msilc_windows_debug_win32_prtest\LLVM\tools\llvm-msilc\lib\Reader\reader.cpp(6565): error C2228: left of '.useMarkedBlockAnnotation' must have class/struct/union [d:\j\workspace\dotnet_llvm-msilc_windows_debug_win32_prtest\build_debug_win32\tools\llvm-msilc\lib\Reader\msilcReader.vcxproj]
D:\j\workspace\dotnet_llvm-msilc_windows_debug_win32_prtest\LLVM\tools\llvm-msilc\lib\Reader\reader.cpp(8088): error C2079: '__marker_onlyOneAllowedPerScope' uses undefined class 'BlockMarker' [d:\j\workspace\dotnet_llvm-msilc_windows_debug_win32_prtest\build_debug_win32\tools\llvm-msilc\lib\Reader\msilcReader.vcxproj]
D:\j\workspace\dotnet_llvm-msilc_windows_debug_win32_prtest\LLVM\tools\llvm-msilc\lib\Reader\reader.cpp(8088): error C2228: left of '.markBlock' must have class/struct/union [d:\j\workspace\dotnet_llvm-msilc_windows_debug_win32_prtest\build_debug_win32\tools\llvm-msilc\lib\Reader\msilcReader.vcxproj]
D:\j\workspace\dotnet_llvm-msilc_windows_debug_win32_prtest\LLVM\tools\llvm-msilc\lib\Reader\reader.cpp(8088): error C2228: left of '.useMarkedBlockAnnotation' must have class/struct/union [d:\j\workspace\dotnet_llvm-msilc_windows_debug_win32_prtest\build_debug_win32\tools\llvm-msilc\lib\Reader\msilcReader.vcxproj]
D:\j\workspace\dotnet_llvm-msilc_windows_debug_win32_prtest\LLVM\tools\llvm-msilc\include\clr\staticcontract.h(326): error C2061: syntax error : identifier 'UINT' (D:\j\workspace\dotnet_llvm-msilc_windows_debug_win32_prtest\LLVM\tools\llvm-msilc\lib\Reader\readerir.cpp) [d:\j\workspace\dotnet_llvm-msilc_windows_debug_win32_prtest\build_debug_win32\tools\llvm-msilc\lib\Reader\msilcReader.vcxproj]
D:\j\workspace\dotnet_llvm-msilc_windows_debug_win32_prtest\LLVM\tools\llvm-msilc\include\clr\staticcontract.h(350): error C2992: 'BlockMarker' : invalid or missing template parameter list (D:\j\workspace\dotnet_llvm-msilc_windows_debug_win32_prtest\LLVM\tools\llvm-msilc\lib\Reader\readerir.cpp) [d:\j\workspace\dotnet_llvm-msilc_windows_debug_win32_prtest\build_debug_win32\tools\llvm-msilc\lib\Reader\msilcReader.vcxproj]
D:\j\workspace\dotnet_llvm-msilc_windows_debug_win32_prtest\LLVM\tools\llvm-msilc\lib\Reader\readerir.cpp(3188): error C2079: '__marker_onlyOneAllowedPerScope' uses undefined class 'BlockMarker' [d:\j\workspace\dotnet_llvm-msilc_windows_debug_win32_prtest\build_debug_win32\tools\llvm-msilc\lib\Reader\msilcReader.vcxproj]
D:\j\workspace\dotnet_llvm-msilc_windows_debug_win32_prtest\LLVM\tools\llvm-msilc\lib\Reader\readerir.cpp(3188): error C2228: left of '.markBlock' must have class/struct/union [d:\j\workspace\dotnet_llvm-msilc_windows_debug_win32_prtest\build_debug_win32\tools\llvm-msilc\lib\Reader\msilcReader.vcxproj]
D:\j\workspace\dotnet_llvm-msilc_windows_debug_win32_prtest\LLVM\tools\llvm-msilc\lib\Reader\readerir.cpp(3188): error C2228: left of '.useMarkedBlockAnnotation' must have class/struct/union [d:\j\workspace\dotnet_llvm-msilc_windows_debug_win32_prtest\build_debug_win32\tools\llvm-msilc\lib\Reader\msilcReader.vcxproj]

Insert explicit test and conditional throw for integer division. Should be straightforward after #63 lays the groundwork.

Part of #13.

The EH clauses we're generating aren't exactly the same as the pdata that LLVM will be generating; need to override/translate as appropriate.

The plan is to first implement this when just catch handlers are processed in the reader, so the initial implementation can take advantage of that if convenient.

Part of #13.

Should go smoothly with #68 already in place.

Part of #13.

What's currently implemented is a stub to allow testing programs that may statically include EH constructs, but don't dynamically raise exceptions. We will of course need a functional implementation; this is an overall tracking issue for that.

The tree contains a document describing the overall status/plan for exception handling.

Current status:

1. Stub EH support
   • Reader discards catch/filter/fault handlers
   • Explicit throw becomes helper call
   • Continuation passing for finally handlers invoked by leave (#260)
   • Implicit exceptions expanded to explicit test/throw sequences
     • Null dereference (#63)
     • Divide by zero (#64)
     • Arithmetic overflow (#65)
     • Convert with overflow (#48)
     • Array bounds checks (#187/#188)
     • Array store checks (#188)
2. Handler bring-up in EH branch
   • Catch handler support
     • In reader (includes updating throws to use invoke rather than call with EH edge to landingpad) (#66)
     • Funclet prolog/epilog generation, Previous Stack Pointer Symbol handshake implemented (#67)
     • EH Clause generation (#68)
     • Reporting funclets back to EE with parent functions in .text (#69)
   • Support for rethrow (#70)
   • Finally handler support
     • In reader (includes leave processing, continuation selection) (#71)
     • EH Clause generation (#73)
   • Filter handler support
     • In reader (includes early outlining) (#74)
     • EH Clause generation (#75)
   • Fault handler support (#76)
3. Migrate changes back into master branch
4. EH-specific optimizations
   • Finally cloning
   • Others TBD
5. Support for other target architectures
6. Support for ahead-of-time compilation

Currently we're building with the LLVM MCJIT. Consider the new ORC infrastructure. Look at options or improvements that would help our model.

This includes the following msil instructions: add.ovf, add.ovf.un, mul.ovf, mul.ovf.un, sub.ovf, sub.ovf.un.

Scrub any MS corp net references from the test scripts and allow testing against the CoreCLR package.

When the updated testing script is in, move testing legs to the open CI.

Note we need to be careful not to accidentally pre-announce LLILC with this work.

Need to flesh out the driver handshake to package up the main function and funclets when reporting generated code to the EE.

Part of #13.

• CoreCLR JITing arch.
• Outline how LLILC will use LLVM
• Relationship to MCJIT and ORC frameworks

This includes unbox and unbox.any msil instructions.

Intrinsic definition and lowering (to nothing; intrinsic is just to represent sideffects of outer filters).

Part of #13.

When we see an MSIL remainder on floating types, we create an LLVM frem instruction, which lowers to a call to the CRT's fmod(), which we then fail to handle when processing coff relocations.

Instead float remainder needs to be translated to a call to the appropriate JIT helper. We can do this in the reader or figure out how to override the lowering and do it there so the remainder is exposed to optimizations in between.

This impacts the DblRem and FPRem tests in the CoreCLR test suite.

Add null checks against the object pointer for ldfld, stfld, ldloca, ldelema, ldflda, ldelema.
Checks should use an explicit compare+branch+throw sequence.
Throw will use call rather than invoke for now (stub EH support).
Use separate throw block for each test, at least for now (it facilitates debugging, vs. shared throw block for all tests in the same EH context).
Tricky bit will be making sure the reader's flow graph bookkeeping doesn't get messed up as blocks are split. May need separate notions of MSIL block and LLVM block.

Part of #13.

Write an LLVM phase to insert safepoints into the IR.

Find out how to extend liveness in LLVM and use that to ensure values are kept alive throughout a method body.

Includes leave processing and insertion of continuation selector variables.

Part of #13.