<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Tue, Nov 4, 2014 at 9:10 PM, Bruce Hoult <span dir="ltr"><<a href="mailto:bruce@hoult.org" target="_blank" class="cremed">bruce@hoult.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><span>On Wed, Nov 5, 2014 at 2:30 PM, Sean Silva <span dir="ltr"><<a href="mailto:chisophugis@gmail.com" target="_blank" class="cremed">chisophugis@gmail.com</a>></span> wrote:<br></span><div class="gmail_extra"><div class="gmail_quote"><span><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">> Does Apple support library/middleware providers shipping bitcode instead<br><div class="gmail_extra"><div class="gmail_quote"><span><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span>
> of object code?<br>
<br>
</span>No.<br></blockquote><div><br></div></span><div>Are there ever any plans to do so?</div><div>(this question also goes out to every other vendor that is shipping an LTO toolchain or plans to. Chad?)</div><div><br></div><div>I'm just trying to figure out how much of a Sony-specific issue this is.</div></div></div></div></blockquote><div><br></div></span><div>The new Andoid ART compiler compiles Dalvik bytecode in standard APKs to native code on the phone at install time.  It also has in the source code a, possibly still experimental, "portable mode" that compiles to LLVM bitcode instead.</div></div></div></div></blockquote><div><br></div><div>This is completely inaccurate. ART's portable mode used LLVM's IRBuilder to construct IR and then lower it immediately, as it is an ahead-of-time compiler that executes on the device itself. It never stores the IR out to disk. Applications continue to use dex for portable distribution.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><br></div><div>I assume (but don't know) this means this would happen on the application developer's host machine and then be distributed in the Play Store (or otherwise) as bitcode.</div><div><br></div><div>Which would raise large and definite bitcode versioning problems.</div></div></div></div></blockquote><div><br></div><div>On the other hand, Android RenderScript does use LLVM bitcode as its portable storage format. We have bitcode writers stretching back to 2 funky versions of LLVM 2.9 (really pre-3.0). The default writer for us is based on 3.2, and we upconvert any pre-3.x bitcode that we have to 3.2 (or something more modern if we can). There have definitely been issue in the past (attribute changes, removal/update of opcodes, etc.), but we have always found a way to adapt. We are definitely aware that any 4.x change could break our readers/writers, although we remain hopeful that we will adapt once again. All of our bitcode conversion/translation tools are available in the public Android open source project. Note that we only need to deal with the C subset of things (so no exception handling), and we currently will drop/ignore any metadata that might break things (so debugging has been a challenge).</div><div><br></div><div>Steve</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><br></div></div></div></div>
<br>_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:LLVMdev@cs.uiuc.edu" target="_blank" class="cremed">LLVMdev@cs.uiuc.edu</a>         <a href="http://llvm.cs.uiuc.edu" target="_blank" class="cremed">http://llvm.cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev" target="_blank" class="cremed">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a><br>
<br></blockquote></div><br></div></div>