[LLVMdev] Using the unused "version" field in the bitcode wrapper (redux)

[Stephen Hines]

On Tue, Nov 4, 2014 at 9:10 PM, Bruce Hoult <bruce at hoult.org> wrote:

> On Wed, Nov 5, 2014 at 2:30 PM, Sean Silva <chisophugis at gmail.com> wrote:
>
>> > Does Apple support library/middleware providers shipping bitcode instead
>>
>>> > of object code?
>>>
>>> No.
>>>
>>
>> Are there ever any plans to do so?
>> (this question also goes out to every other vendor that is shipping an
>> LTO toolchain or plans to. Chad?)
>>
>> I'm just trying to figure out how much of a Sony-specific issue this is.
>>
>
> 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.
>

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.


>
> 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.
>
> Which would raise large and definite bitcode versioning problems.
>

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).

Steve


>
>
> _______________________________________________
> 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/20141106/bfcf6aa6/attachment.html>