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

Tue Dec 3 14:44:31 PST 2013

I have a significant chunk of notes from my experience with garbage
collector integration with LLVM that I'd be happy to contribute to this
effort.

The original notes live here:
https://code.google.com/p/epoch-language/wiki/GarbageCollectionScheme

I imagine it would be preferred if that document was formatted and edited
to match the existing efforts; I'll try and start converting it over in the
next several days and submit a pull req when I've got a finished chapter.

I also have some miscellaneous notes from my other work on the Epoch
language that might be worth including, I'll have to comb through them and
see what I have that's not already covered in this writeup.

 - Mike

On Tue, Dec 3, 2013 at 3:55 AM, Mikael Lyngvig <mikael at lyngvig.org> wrote:

> Hi Philip,
>
> Thanks for your great list of ideas for the document!
>
> I don't really have a scope for the document beyond: If it something that
> requires mapping from high-level to LLVM IR, I think it should go into the
> document.  I started out using C++ examples because  many people know C++.
>  I am personally mostly an advocate of statically checked languages but I
> don't see that as a reason to not include information of relevance to
> non-statically checked languages.   As for garbage collection, well, more
> and more languages are making use of that so I think it is highly relevant
> to the document.  I think all of the issues you have mentioned belong in
> this document, although I am not sure I'll be the best to write all of the
> document.  I sort of hope that everybody will add their pieces so that we
> get a huge document that addresses nearly all the needs of somebody who is
> going to start on or be using LLVM IR.
>
> You are all more than welcome to branch the document at GitHub, add your
> corrections and even entire chapters, and I'll be happy to merge it all
> back to a single document.
>
>
> -- Mikael
>
>
> 2013/12/2 Philip Reames <listmail at philipreames.com>
>
>> 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
>> _______________________________________________
>> LLVM Developers mailing list
>> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>>
>
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20131203/e34c4228/attachment.html>