[llvm-dev] BoF: Shipping Software as LLVM IR (@Upcoming Dev Mtg)

[Will Dietz via llvm-dev]

On Thu, Oct 27, 2016 at 3:59 PM, Steven Wu <stevenwu at apple.com> wrote:
> Hi
>
> I am late to the party. Here is my personal take of the topic:

No worries, better late than never! Thanks for chiming in!

>
> * Do you ship software as IR today? What lessons have you learned?
> Yes. We accept AppStore submission in bitcode (LLVM IR). The core function
> in clang is upstreamed and you can look up the related code path triggered
> by -fembed-bitcode option.

I've looked at this and what's visible from ld64 source in terms of
how it's used,
I'd love to help implement similar functionality in other linkers (or
at least LLD)
if that's something folks are interested in.

>
> * Challenges of shipping software as IR
> Compatibility: We are trying to enhance the bitcode compatibility tests but
> most of them only covers the bitcode reader. But the compatibility issue
> goes way beyond that. It is hard to keep the semantics of the original
> program while the toolchain keeps evolving. The issues I have been seen so
> far: verifier update to tighten the constraints, backend bug fixes, symbol
> resolution changes, etc.

Very interesting! This is something very important to me as well.
Not so much for the compatibility reasons (although of course that's
very important as well!)
but because of the problems you mention in terms of having clear
semantics of the programs.
Others in my group are working on things like formal semantics for
LLVM that can be used
to address this in the long term.  For now in ALLVM we simply pin a
particular "version"
(I can explain, but this is much more precise than an SVN revision)
in terms of specifying the intended semantics of the IR.  I'd love to do better,
if nothing else this doesn't scale over time particularly well.

This is important for many reasons-- for having sound analyses,
for security analysis, and to enable developers to test/inspect
code on their end and have some confidence about these things being
preserved when the code is actually executed.


> Debugging: How do you debug the shipped bitcode running on a platform with
> some other toolchain? Traditionally, you can ship a stripped binary while
> keeping a version that is contains debug information. You can use that debug
> information to map the crash report to a specific line. How does that work
> in the all bitcode world?

Absolutely! This has been discussed quite a bit in our group, but I don't
have any great answers on the subject yet.  I'd like to better
understand the use-cases
in mind before moving forward with anything more than generally saying
ti's important and I'd like to facilitate this best we can :).

> Privacy: How to you hide the sensitive information in the source code away
> from bitcode? This is includes internal types and function interfaces, debug
> information (if you decide to ship them) and etc.
>

This has some very interesting ramifications when combined with the
previous goal,
and I think there are a lot of hard problems in doing this right.
If for no other reason than the fun of the challenge this seems fascinating :).
Also I'm interested in what people consider sensitive/private,
this seems like a difficult thing to evaluate.

Again having looked at the ld64 bits regarding this I'm aware of the issue
but only having my inferences from the code... as far as addressing
this in a community sense I think a good start would be pinning down
the requirements here.

> * What tools or infrastructure would help make that happen?
> It will be great to have standard tooling in LLVM to deal with privacy issue
> to strip away these informations before shipping. It will be even better if
> you can restore them later for debugging.

Yes!

> LLD might also helps with some of the problems above by having an integrated
> tool to ensure consistent symbol resolution.

Absolutely.

>
> Thanks
>
> Steven
>
>
> On Oct 17, 2016, at 1:20 PM, Mehdi Amini via llvm-dev
> <llvm-dev at lists.llvm.org> wrote:
>
> Hi Vikram,
>
> It is a bit more that just “efficient (de)serialization” as there is some
> amount of tradeoff to make between “size” vs “speed” vs “flexibility” (which
> are all some sort of “efficient”).
> For instance what if we get a faster deserialization but got larger size?
> That might be an issue for some people who’d like to ship bitcode.
> Another thing is that we may get better speed/size by optimizing for the
> “streaming” case but losing the flexibility of loading only a subpart of the
> bitcode.
>
> This is where I’d be interested (and I’ll pay attention) during the BoF to
> hear about all the use cases folks are envisioning.
>
> —
> Mehdi
>
> On Oct 17, 2016, at 6:55 AM, Adve, Vikram Sadanand <vadve at illinois.edu>
> wrote:
>
> Hi Mehdi,
>
> Yes, we did see your earlier post.  Efficient (de)serialization is
> definitely important for both exporting (a la LTO and ThinLTO) and for
> shipping code as IR.  I expect most use cases of the latter would benefit.
>
> -—Vikram
>
> // Vikram S. Adve
> // Professor, Department of Computer Science
> // University of Illinois at Urbana-Champaign
> // vadve at illinois.edu
> // http://llvm.org
>
>
> On Oct 14, 2016, at 2:41 PM, Mehdi Amini <mehdi.amini at apple.com> wrote:
>
> Hi,
>
> I think as soon as you want to have long-lived IR, the bitcode serialization
> is a corner stone piece of the system.
> Somehow related, I posted this recently to llvm-dev:
> http://lists.llvm.org/pipermail/llvm-dev/2016-September/105273.html ; I’d be
> interested how we could leverage a better serialization for various
> use-cases!
>
> Best,
>
> —
> Mehdi
>
>
> On Oct 14, 2016, at 11:32 AM, Will Dietz via llvm-dev
> <llvm-dev at lists.llvm.org> wrote:
>
> Hi LLVM’ers!
>
> We are hosting a BoF at this year's Dev Meeting on a subject we hope will be
> of interest to some (many?) of you:
> shipping software (entirely) as LLVM IR.
>
> You can find our proposal in the meeting schedule online:
>
> https://llvmdevelopersmeetingbay2016.sched.org/event/8Yzq/shipping-software-as-llvm-ir
>
> The BoF is scheduled to last 45 minutes, which will go by very quickly!
> To make the best use of the time, we'd like to get a head-start on some of
> the discussions,
> and get a feel for what topics people are most interested in discussing.
> To start things off, here are a few suggestions for things to discuss.
> Thoughts -- and suggestions for additional topics -- welcome.
>
> * Do you ship software as IR today? What lessons have you learned?
> * Challenges of shipping software as IR
> * Representing software: Beyond a single module
> * From build systems to LLVM IR: toolchains and more
> * What would you do with a platform where everything was available as LLVM
> IR?
> * What tools or infrastructure would help make that happen?
>
> (Some background to explain why we’re interested in this topic.)
> ALLVM: We have a project in our group exploring the benefits of shipping
> *all* software on a system as IR.  We are building a prototype ALLVM system
> that makes it relatively easy to package and ship software in this way.
> We are researching the benefits this could provide for performance and
> for general software development.  We aim to make the ALLVM prototype
> available in open source form to enable other groups to explore these goals.
> Contact us off-list if you’d like to learn more about the ALLVM project.
>
> ~Will (and Vikram)
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
>
>
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
>