<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Aug 2, 2016 at 10:07 PM, Hongbin Zheng <span dir="ltr"><<a href="mailto:etherzhhb@gmail.com" target="_blank" class="gmail-cremed cremed">etherzhhb@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Thanks Steve and Mehdi for the explanation.<div><br></div><div>Steve,</div><div><br></div><div>I am a little be confused by looking at the code in <a href="https://android.googlesource.com/platform/frameworks/compile/libbcc/+/master/bcinfo/BitReader_3_0/BitcodeReader.cpp" target="_blank" class="gmail-cremed cremed">https://android.googlesource.com/platform/frameworks/compile/libbcc/+/master/bcinfo/BitReader_3_0/BitcodeReader.cpp</a>. Looks like the BitcodeReader do some translation while reading the bitcode. If LLVM ToT can read the bitcode of LLVM 3.0, while can't we just use the bitcode reader in LLVM ToT?</div></div></blockquote><div><br></div><div>Ah, 3_0 is a bit of a misnomer. It is actually a 2.9 (pre-3.0) bitcode format that this one reads. I would suggest that you (and most everyone else on Earth, actually) ignore the readers that we have. We had an unstable snapshot of LLVM when we first released, and nobody noticed. Unfortunately, LLVM doesn't respect non-release bitcode formats, so we had to check in our own readers to handle those cases.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><br></div><div>Also, the bitcode "downgrade" is done by :</div><div><div>// Use the LLVM 3.2 bitcode writer, instead of the top-of-tree version.</div><div>llvm_3_2::WriteBitcodeToFile(module, OS);</div></div><div><br></div><div>Is the corresponding source code also available? if so could you point me to the corresponding file?</div></div></blockquote><div><br></div><div><a href="https://android.googlesource.com/platform/frameworks/compile/slang/+/refs/heads/master/BitWriter_3_2/">https://android.googlesource.com/platform/frameworks/compile/slang/+/refs/heads/master/BitWriter_3_2/</a> is the location I mentioned before for the writer. There are 2 different RenderScript projects that contain our bitcode libraries (one is readers - libbcc, the other holds the writers - slang).<br></div><div><br></div><div>Thanks,</div><div>Steve</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><br></div><div>Thanks again</div><span class="gmail-HOEnZb"><font color="#888888"><div>Hongbin</div><div><div><br></div></div></font></span></div><div class="gmail-HOEnZb"><div class="gmail-h5"><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Aug 2, 2016 at 9:29 PM, Stephen Hines <span dir="ltr"><<a href="mailto:srhines@google.com" target="_blank" class="gmail-cremed cremed">srhines@google.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Ah, I had missed that. That is great news to hear, actually. The RS team had already started planning how to adapt their translator to have a 4.0 (really 3.x) reader for when the dreaded 4.1/5.0 release would make things difficult. I guess they can reclaim some of their time now. ;) Thank you so much for clarifying this.<div><br></div><div>Thanks,</div><div>Steve</div></div><div class="gmail-m_7082285659639129437HOEnZb"><div class="gmail-m_7082285659639129437h5"><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Aug 2, 2016 at 8:56 PM, Mehdi Amini <span dir="ltr"><<a href="mailto:mehdi.amini@apple.com" target="_blank" class="gmail-cremed cremed">mehdi.amini@apple.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word"><br><div><span><blockquote type="cite"><div>On Aug 2, 2016, at 8:49 PM, Stephen Hines <<a href="mailto:srhines@google.com" target="_blank" class="gmail-cremed cremed">srhines@google.com</a>> wrote:</div><br><div><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Aug 2, 2016 at 8:44 PM, Mehdi Amini <span dir="ltr"><<a href="mailto:mehdi.amini@apple.com" target="_blank" class="gmail-cremed cremed">mehdi.amini@apple.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word"><br><div><span><blockquote type="cite"><div>On Aug 2, 2016, at 8:38 PM, Stephen Hines via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank" class="gmail-cremed cremed">llvm-dev@lists.llvm.org</a>> wrote:</div><br><div><div dir="ltr">Hi Hongbin,<br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Aug 2, 2016 at 8:26 PM, Hongbin Zheng <span dir="ltr"><<a href="mailto:etherzhhb@gmail.com" target="_blank" class="gmail-cremed cremed">etherzhhb@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Hi Steve,<div><br></div><div>Several people told me that LLVM TOT bcreader can read odder version of bitcode without any problem. Do you know the oldest version of bitcode that the TOT bitcode reader supports?</div></div></blockquote><div><br></div><div>The current policy is that LLVM can read bitcode for any prior version with the same major version number. Thus 3.9svn can read all the way back to 3.0 (and also 3.1/3.2/...). It cannot read 2.9 or earlier bitcode. It was also policy that the next major release (but only the .0 version) will be able to read the prior version of bitcode too. Thus 4.0 is expected to read 3.x bitcode as well. 4.1 is not expected to read 3.x bitcode, and it will be an error to try to do so. With the new shift to version numbering (i.e. major versions are coming out faster - check the recent archives here), I am not sure how reliable bitcode will be as a storage format. This is something that the RenderScript team is also planning for, since 4.0 will be the last supported release that can easily read the 3.2 IR that we currently generate.</div></div></div></div></div></blockquote><div><br></div></span><div>No this is not the current situation: with the version numbering change, the policy changed as well. The new and current policy is: we support bitcode since 3.0 till we changed our mind.</div><div>Note also that LLVM 4.1 will be a minor “patch” release (like 3.8.1), you can expect LLVM 5.0 to be released ~6 months after LLVM 4.0.</div></div></div></blockquote><div><br></div><div>Isn't that consistent with what I wrote</div></div></div></div></div></blockquote><div><br></div></span><div>Sorry if mis-explained, let me try again.</div><span><div><br></div><blockquote type="cite"><div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div> (i.e. 4.0 will read 3.x,</div></div></div></div></div></blockquote><div><br></div></span><div>This is correct.</div><span><br><blockquote type="cite"><div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div> but anything afterwards will not)?</div></div></div></div></div></blockquote><div><br></div></span><div>This isn’t. The policy was till 3.8:: "The bitcode format produced by a X.Y release will be readable by all following X.Z releases and the (X+1).0 release.” (Source <a href="http://llvm.org/releases/3.8.1/docs/DeveloperPolicy.html#ir-backwards-compatibility" target="_blank" class="gmail-cremed cremed">http://llvm.org/releases/3.8.1/docs/DeveloperPolicy.html#ir-backwards-compatibility</a> )</div><div>This policy is supporting your claim. However with the version numbering change, the policy is now:  "The current LLVM version supports loading any bitcode since version 3.0.” (Source: <a href="http://llvm.org/docs/DeveloperPolicy.html#ir-backwards-compatibility" target="_blank" class="gmail-cremed cremed">http://llvm.org/docs/DeveloperPolicy.html#ir-backwards-compatibility</a> )</div><div><br></div><div>Unless we change the policy (and I expect it would need a strong motivation), we will support the 3.0 bitcode in LLVM 5.0, LLVM 6.0, etc.</div><div><br></div><div>The intent is that the new version numbering does not lower the bar on the bitcode backward compatibility.</div><span><div><br></div><div><br></div><blockquote type="cite"><div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>Is 4.0 not going to be able to read 3.x at all? If so, that seems like a big surprise for quite a few out-of-tree clients of LLVM. I didn't see anything altering the policy in that email thread, and only assumed that the more rapid major release cycle was going to make things worse (but still consistent with the old policy in theory).</div></div></div></div></div></blockquote><div><br></div></span><div>I hope it is more clear now.</div><div><div><div><br></div><div><div>— </div><div>Mehdi</div><div><br></div></div><br><blockquote type="cite"><div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word"><div><div><div><div><br></div><br><blockquote type="cite"><div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><br></div><div>Also, why do you generate bitcode instead of the textural representation, i.e. the "ll" file, for older version of LLVM? I guess generating "ll" code is simpler.</div></div></blockquote><div><br></div><div>Our project has been using the binary bitcode format for about 6 years now (starting with 2.9). We finally stabilized on 3.2 bitcode a few years ago, rather than continuing to add new versions. The text version of LLVM IR has no compatibility guarantees (i.e. 3.9svn can't read 3.8 textual IR). It also takes up more space than the binary representation, which was an initial concern for our product too.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><br></div><div>Another approach I am thinking is linking to two different version of LLVM at the same time, and use the old version of IRBuilder to build bitcode from new version of LLVM IR. How do you think about this?</div></div></blockquote><div><br></div><div>That is exactly what our bitcode translator is essentially doing. We use the TOT IRBuilder and also link in (forked) past readers/writers. This does mean that we have to adapt the APIs for the past readers/writers when IRBuilder changes, but that doesn't happen all that often.</div><div><br></div><div>Thanks,</div><div>Steve</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><br></div><div>At last, we also do not support<span style="font-size:12.8px"> </span><span style="font-size:12.8px">exception handling:)</span></div><div><br></div><div><br></div><div>Thanks.</div><span><font color="#888888"><div>Hongbin</div></font></span><div><div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Aug 2, 2016 at 7:26 PM, Stephen Hines <span dir="ltr"><<a href="mailto:srhines@google.com" target="_blank" class="gmail-cremed cremed">srhines@google.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Hi Hongbin,<br><div class="gmail_extra"><br><div class="gmail_quote"><span>On Tue, Aug 2, 2016 at 5:42 PM, Jakub Kuderski <span dir="ltr"><<a href="mailto:kubakuderski+llvm@gmail.com" target="_blank" class="gmail-cremed cremed">kubakuderski+llvm@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><span><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span style="font-size:12.8px">I also have a look at the code, looks like it directly parse the bitcode and build in memory representation in a different LLVM version than the bitcode. Is this correct?</span> </blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span style="font-size:12.8px">According to your description, I guess the </span><span style="font-size:12.8px">BitCodeWriter should be the one to do the bitcode version downgrade, right?</span> </blockquote></span><div>I think so.<br><br>I don't know much about it and don't want to give you misleading information; I'm cc-ing Stephen. <br> </div></div><div><div><div class="gmail_extra"><br><div class="gmail_quote">On 2 August 2016 at 16:53, Hongbin Zheng <span dir="ltr"><<a href="mailto:etherzhhb@gmail.com" target="_blank" class="gmail-cremed cremed">etherzhhb@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Thanks Jakub. Looks Like I didn't rely all.<div><br></div><div>I also have a look at the code, looks like it directly parse the bitcode and build in memory representation in a different LLVM version than the bitcode. Is this correct?</div></div></blockquote></div></div></div></div></blockquote><div><br></div></span><div>Yes, it uses a TOT reader (which can support reading all 3.x Bitcode), and then lowers the in-memory representation back through a forked version of the 3.2 BitcodeWriter.</div><span><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><br></div><div>According to your description, I guess the <span style="font-size:12.8px">BitCodeWriter should be the one to do the bitcode version downgrade, right?</span></div></div></blockquote></div></div></div></div></blockquote><div><br></div></span><div>Yes, we use a separately-maintained LLVM 3.2 BticodeWriter to generate the downgraded form. We also have 2 other BitcodeWriters based on roughly LLVM 2.9 (but not exactly 2.9, so I would steer you away from those). <a href="https://android.googlesource.com/platform/frameworks/compile/slang/+/refs/heads/master/BitWriter_3_2/" target="_blank" class="gmail-cremed cremed">https://android.googlesource.com/platform/frameworks/compile/slang/+/refs/heads/master/BitWriter_3_2/</a> is a link to the actual primary writer we use.</div><span><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><br></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">Does this took work on LLVM 3.9svn?</span></div></div></blockquote></div></div></div></div></blockquote><div><br></div></span><div>It currently only works up to LLVM r256229. We will most likely be updating it to closer to TOT LLVM in the next few months, but it isn't an extreme priority for us right now. Usually, maintenance requires us to fix up any internal API differences that might have changed for walking/manipulating the in-memory representation.</div><span><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">And could you give some hints about how you test the bitcode translator?</span></div></div></blockquote></div></div></div></div></blockquote><div><br></div></span><div>We have very few tests for this, and mostly rely on older Android devices running applications that we build using the translated bitcode. If the older device (which only has LLVM 3.2) passes those tests, we consider it a success. I suppose that we could take a 3.2-era BitcodeReader and wash bitcode back and forth through it, but I don't work directly on RenderScript these days.</div><div><br></div><div>One word of caution about reusing our BitcodeWriter passes - we have only ever cared about C99, so we definitely removed some code that relates to exception handling (and possibly some other C++-specific features). We also only expect IR constructs that come about from normal C99 compilation/optimization, so if you have handwritten IR, there may be unsupported instructions that we don't know how to generate legacy bitcode for.</div><div><br></div><div>Thanks,</div><div>Steve</div><div><div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">Thanks</span></div><span><font color="#888888"><div><span style="font-size:12.8px">Hongbin</span></div><div><br><div><br></div><div><br></div></div></font></span></div><div><div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Aug 2, 2016 at 3:25 PM, Jakub Kuderski <span dir="ltr"><<a href="mailto:kubakuderski+llvm@gmail.com" target="_blank" class="gmail-cremed cremed">kubakuderski+llvm@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">I'm not sure if it was intended, but I think that you responded only to me (not to the list).<br><br>Anyway, RenderScript currently uses llvm 3.2 IR as binary representation/exchangeable format, but the llvm version is higher internally. Essentially, there it reads old bitcode and operates on the newer one in memory. When it's done, it's also able to output bitcode in the old format. The corresponding classes should be something like BitCodeReader and BitCodeWriter.<br>The reader/writer is maintained to work with Android's llvm version, which follows upstream llvm version.<br><br>I haven't worked on it myself, but if you have some specific questions, I should be able to point you to appropriate people.<br><br>Regards<br></div><div><div><div class="gmail_extra"><br><div class="gmail_quote">On 2 August 2016 at 15:17, Hongbin Zheng <span dir="ltr"><<a href="mailto:etherzhhb@gmail.com" target="_blank" class="gmail-cremed cremed">etherzhhb@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Hi Jakub,<div><br></div><div>Thanks a lot. Do you have any document about this tool? or could you gave me a rough idea what it do?</div><div><br></div><div>Thanks</div><span><font color="#888888"><div>Hongbin</div></font></span></div><div><div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Aug 2, 2016 at 3:06 PM, Jakub Kuderski <span dir="ltr"><<a href="mailto:kubakuderski+llvm@gmail.com" target="_blank" class="gmail-cremed cremed">kubakuderski+llvm@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Hi Hongbin,<br><br>Android's RenderScript uses a tool like that. You can find the sources here: <a href="https://android.googlesource.com/platform/frameworks/compile/libbcc/+/master/bcinfo/" target="_blank" class="gmail-cremed cremed">https://android.googlesource.com/platform/frameworks/compile/libbcc/+/master/bcinfo/</a> .<br><br>Best,<br>Jakub<br><br><div class="gmail_extra"><br><div class="gmail_quote"><div><div>On 2 August 2016 at 11:10, Hongbin Zheng via llvm-dev <span dir="ltr"><<a href="mailto:llvm-dev@lists.llvm.org" target="_blank" class="gmail-cremed cremed">llvm-dev@lists.llvm.org</a>></span> wrote:<br></div></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div><div dir="ltr">Hi mailing list,<div><br></div><div>I has been working on a large project that is based on LLVM 3.1. Recently we are thinking to introduce an LLVM bc converter from LLVM 3.9 to LLVM 3.1, such that we can introduce some of the newest LLVM analyses and optimizations to our  LLVM 3.1 based project.</div><div><br></div><div>Have you worked on similar things that converting LLVM bc downward and has anything to share?</div><div><br></div><div>Thanks</div><span><font color="#888888"><div>Hongbin</div></font></span></div>
<br></div></div>_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank" class="gmail-cremed cremed">llvm-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank" class="gmail-cremed cremed">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
<br></blockquote></div><br></div></div>
</blockquote></div><br></div>
</div></div></blockquote></div><br></div>
</div></div></blockquote></div><br></div>
</div></div></blockquote></div><br></div>
</div></div></blockquote></div></div></div><br></div></div>
</blockquote></div><br></div></div></div></div>
</blockquote></div><br></div></div>
_______________________________________________<br>LLVM Developers mailing list<br><a href="mailto:llvm-dev@lists.llvm.org" target="_blank" class="gmail-cremed cremed">llvm-dev@lists.llvm.org</a><br><a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" target="_blank" class="gmail-cremed cremed">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br></div></blockquote></div></div></div><br></div></blockquote></div><br></div></div>
</div></blockquote></div></div></div><br></div></blockquote></div><br></div>
</div></div></blockquote></div><br></div>
</div></div></blockquote></div><br></div></div>