<div dir="ltr">Hi Chris,<div><br></div><div>Thanks for the supporting words! I'm pushing the document both for egoistic motives (like so many others, I'll learn a ton from this document) and for altruistic motives - the easier it is to implement a new language, the more interesting and highly well-thought out languages we will see in the future. And I see it as my purpose, as a mostly black-box user of LLVM, to enhance the experience for newcomers so that they don't turn away and waste time on other projects just because it all seems rather overwhelming at first.<br>
<div><br></div><div>I couldn't recall having heard of the "alloca trick", but a Google search revealed that this is described in the Kaleidoscope sample. I will be more than happy to include it - that's precisely what the document is also for: Teaching people all the things that cannot easily be said in a Language Reference. In a way, the name is already now becoming poorly chosen. Because I begin to see a User's Guide forming in the horizon. And that would go really well with the Language Reference; most products have both.</div>
</div><div><br></div><div>I've added all of your suggestions to my to-do list, which I'll write into the document later today, so that none of the suggestions get lost. Yes, the unions I thought about at some point but forgot about them again. I also feel that there needs to be good documentation of GEP and extractvalue - when to use one and when to use the other. In fact, the whole structure/union aspect seems mostly overlooked because I got too preoccupied with the class stuff.</div>
<div><br></div><div>I am not at all opposed to working directly from <a href="http://llvm.org/docs">llvm.org/docs</a>, the only thing is that I do a lot of small commits with an occasional large commit here and there, and I wouldn't want to provoke a review whenever I change a single line here or there. The reason I use GitHub is that it provides a nifty, colorized page (<a href="https://github.com/archfrog/llvm-doc/blob/master/MappingHighLevelConstructsToLLVMIR.rst">https://github.com/archfrog/llvm-doc/blob/master/MappingHighLevelConstructsToLLVMIR.rst</a>) that people (including myself) can view without going through the trouble of installing and running Sphinx locally. And also, it allows people to submit reviews by forking, creating an issue, or attaching a comment (all three of which have already been in use). I think it is better that I do it in GitHub for the time being as I tend to make many small, stupid mistakes that I usually discover quite quickly and then fix. Then when I feel I've got something interesting to show people, I can submit a commit and everybody can join in the review.</div>
<div><br></div><div><br></div><div>-- Mikael</div><div><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">2013/12/4 Chris Lattner <span dir="ltr"><<a href="mailto:clattner@apple.com" target="_blank">clattner@apple.com</a>></span><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><br><div><div>On Nov 28, 2013, at 6:07 PM, Mikael Lyngvig <<a href="mailto:mikael@lyngvig.org" target="_blank">mikael@lyngvig.org</a>> wrote:</div>
<br><blockquote type="cite"><div dir="ltr">Hi,<div><br></div><div>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:</div>
<div><br></div><div> <a href="https://github.com/archfrog/llvm-doc/blob/master/MappingHighLevelConstructsToLLVMIR.rst" target="_blank">https://github.com/archfrog/llvm-doc/blob/master/MappingHighLevelConstructsToLLVMIR.rst</a></div>
<div>
<br></div><div><br></div><div>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. </div>
<div><br></div></div></blockquote><br></div><div>This looks really awesome! Great idea starting this, and thank you for pushing it forward. Some thoughts:</div><div><br></div><div>- In "local variables", it would be great to talk about how the "alloca trick" avoids forcing your frontend to build SSA. You could even include an example.</div>
<div><br></div><div>- In the "constants" section, it is probably best to say that "constants that allocate memory" are just global variables in LLVM IR, marked with the 'constant' keyword. It would also be great to mention constant exprs here, since they are a point of confusion (and you introduce them in sizeof).</div>
<div><br></div><div>- Having something that talks about lowering C-style unions to llvm IR would be great :-)</div><div><br></div><div>- A nice new top-level section would be "interoperating with a runtime library", pointing out that not everything needs to be emitted as inline LLVM IR: a frontend can either just call into a runtime library, or it can even emit a call to a runtime library (whose body is also available as IR) and then have the optimizer inline it if run.</div>
<div><br></div><div><br></div><div><blockquote type="cite"><div dir="ltr">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.</div>
</blockquote><br></div><div>Are you interested in just building it in <a href="http://llvm.org/docs?" target="_blank">llvm.org/docs?</a> Unless your workflow is better on github, it seems easier to do it on <a href="http://llvm.org" target="_blank">llvm.org</a> - it would make it easier for other people to chip in.</div>
<span class="HOEnZb"><font color="#888888"><div><br></div><div>-Chris</div></font></span></div></blockquote></div><br></div>