llvm dev - Dec 2013 - [LLVMdev] "Mapping High-Level Constructs to LLVM IR" Github URL

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20131203/6938fb42/attachment.html>

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>

Hi Mike,

That sounds awesome!  I have no experience with implementing garbage
collection at all, so I was wondering if I should do a call for writers.  I
am already overloaded by the prospect of having to learn and document
zero-cost exception handling.  As I said to Dirkjan at one point: I am
probably not the best to write this document, except for the fact that I
have all the time in the world.

If it is too much trouble writing up the notes in reST, you can always do
it in whichever format you prefer and hand it over to me.  I don't mind an
occasional manual reformatting task to cool down my brain a bit ;-)  This
goes for anybody who reads this message and does not like the idea of
having to learn reST just to submit notes or chapters to the final
document.  Submission in every one of these formats are accepted: Word over
to PostScript over to PDF to ASCII to reST.  And even more, if only I can
find a way to read it and/or print it on a Windows box.

I meant to say this earlier on: Anybody with sufficient knowledge and/or
experience is more than welcome to submit one or more chapters to be
included in the final text.  The basic idea is to document all those
trivial and difficult things that go into making a front-end using LLVM.
 The scope of the document is strict LLVM IR, though, so there will be no
mention of the C++ or C API.


-- Mikael


2013/12/3 Michael Lewis <don.apoch at gmail.com>
> 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/466f6821/attachment.html>