[LLVMdev] "Mapping High-Level Constructs to LLVM IR" Github URL

[Philip Reames]

On 11/28/13 6:07 PM, Mikael Lyngvig wrote:
> Hi,
>
> It will probably take a few weeks or a month before the "Mapping 
> High-Level Constructs to LLVM IR" document is ready for prime time. 
>  Until then, you can review and study it at this URL:
>
> https://github.com/archfrog/llvm-doc/blob/master/MappingHighLevelConstructsToLLVMIR.rst
>
>
> Please notice that I specifically do not advocate reviewing the 
> document for a week or two.  But feel free to give me any feedback, 
> comments, and criticism that you may have to share.
>
> Once the document has been finalized and comitted to LLVM, I'll delete 
> the repository at Github - or, perhaps even better, simply make a 
> small page that refers to the official copy in LLVM.
Just want to comment that I strongly approve of your intended goal. 
Depending on how my time shakes out over the next few weeks, I may even 
take some time to write up my own experiences.  I particularly like how 
you have chosen to layout various alternative implementations rather 
than choosing "one true implementation".

A few areas you haven't covered and might want to consider:
- How to enable debug information?  (Line and Function, Variable)
- How to interface with a garbage collector? (link to existing docs)
- How to express a custom calling convention? (link to existing docs)
- Representing constructors, destructors, finalization
- How to examine the stack at runtime?  How to modify it?  (i.e. 
reflection, interjection)
- Representing subtyping checks (with full alias info), TBAA, 
struct-path TBAA
- How to exploit inlining (external, vs within LLVM)?
- How to express array bounds checks for best optimization?
- How to express null pointer checks?
- How to express domain specific optimizations?  (i.e. lock elision, or 
matrix math simplification) (link to existing docs)
- How to optimize call dispatch or field access in dynamic languages? 
(ref new patchpoint intrinsics for inline call caching and field access 
caching)

Out of curiosity, what do you see as the intended scope of this 
document?  I see there being three main categories of languages: pure 
static compilation, "managed languages" (i.e. compile to bytecode + 
runtime system), and pure dynamic languages*.  I could see different 
features and focus for a document geared at each of these camps.  For 
example, the first two are going to be interested in static 
optimization, whereas the last two are going to be interested in 
speculative optimization.   What are your thoughts on this?

* Note: Let's not get too caught up in the categorization.  It's not 
really important where exactly the lines are drawn.

Philip