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

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<mailto:vadve at illinois.edu>
// http://llvm.org


On Oct 14, 2016, at 2:41 PM, Mehdi Amini <mehdi.amini at
apple.com<mailto: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<https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.llvm.org_pipermail_llvm-2Ddev_2016-2DSeptember_105273.html&d=DQMFaQ&c=8hUWFZcy2Z-Za5rBPlktOQ&r=b7uK7dJM4Fx7J_ehsuohEdD-6NdkoLyTwBFfHX-XKcc&m=2ty5V_F2rdMdBJPJVLuXAmeH-EXUvcMMe-ug_QqIqZA&s=byMygV6Z_7kXGJPWr5dD1wi0Gy13O7j0EXYEXDeW5Is&e=>
; 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<mailto: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<https://urldefense.proofpoint.com/v2/url?u=https-3A__llvmdevelopersmeetingbay2016.sched.org_event_8Yzq_shipping-2Dsoftware-2Das-2Dllvm-2Dir&d=DQMFaQ&c=8hUWFZcy2Z-Za5rBPlktOQ&r=b7uK7dJM4Fx7J_ehsuohEdD-6NdkoLyTwBFfHX-XKcc&m=2ty5V_F2rdMdBJPJVLuXAmeH-EXUvcMMe-ug_QqIqZA&s=f7oVXD0X8QKcnInXVH2m-a2ddcj04_t-Qnwbj8dUwmA&e=>

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<mailto:llvm-dev at lists.llvm.org>
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev


-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20161017/d27d1241/attachment.html>

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 <mailto:vadve at illinois.edu>
> // http://llvm.org <http://llvm.org/>
> 
> 
>> On Oct 14, 2016, at 2:41 PM, Mehdi Amini <mehdi.amini at apple.com
<mailto: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
<https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.llvm.org_pipermail_llvm-2Ddev_2016-2DSeptember_105273.html&d=DQMFaQ&c=8hUWFZcy2Z-Za5rBPlktOQ&r=b7uK7dJM4Fx7J_ehsuohEdD-6NdkoLyTwBFfHX-XKcc&m=2ty5V_F2rdMdBJPJVLuXAmeH-EXUvcMMe-ug_QqIqZA&s=byMygV6Z_7kXGJPWr5dD1wi0Gy13O7j0EXYEXDeW5Is&e=>
; 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 <mailto: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
<https://urldefense.proofpoint.com/v2/url?u=https-3A__llvmdevelopersmeetingbay2016.sched.org_event_8Yzq_shipping-2Dsoftware-2Das-2Dllvm-2Dir&d=DQMFaQ&c=8hUWFZcy2Z-Za5rBPlktOQ&r=b7uK7dJM4Fx7J_ehsuohEdD-6NdkoLyTwBFfHX-XKcc&m=2ty5V_F2rdMdBJPJVLuXAmeH-EXUvcMMe-ug_QqIqZA&s=f7oVXD0X8QKcnInXVH2m-a2ddcj04_t-Qnwbj8dUwmA&e=>
>>> 
>>> 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 <mailto:llvm-dev at
lists.llvm.org>
>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
<http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev>
>> 
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20161017/acac73ca/attachment.html>

Hi

I am late to the party. Here is my personal take of the topic:

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

* 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.
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?
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.

* 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.
LLD might also helps with some of the problems above by having an integrated
tool to ensure consistent symbol resolution.

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 <mailto: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 <mailto:vadve at illinois.edu>
>> // http://llvm.org <http://llvm.org/>
>> 
>> 
>>> On Oct 14, 2016, at 2:41 PM, Mehdi Amini <mehdi.amini at
apple.com <mailto: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
<https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.llvm.org_pipermail_llvm-2Ddev_2016-2DSeptember_105273.html&d=DQMFaQ&c=8hUWFZcy2Z-Za5rBPlktOQ&r=b7uK7dJM4Fx7J_ehsuohEdD-6NdkoLyTwBFfHX-XKcc&m=2ty5V_F2rdMdBJPJVLuXAmeH-EXUvcMMe-ug_QqIqZA&s=byMygV6Z_7kXGJPWr5dD1wi0Gy13O7j0EXYEXDeW5Is&e=>
; 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 <mailto: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
<https://urldefense.proofpoint.com/v2/url?u=https-3A__llvmdevelopersmeetingbay2016.sched.org_event_8Yzq_shipping-2Dsoftware-2Das-2Dllvm-2Dir&d=DQMFaQ&c=8hUWFZcy2Z-Za5rBPlktOQ&r=b7uK7dJM4Fx7J_ehsuohEdD-6NdkoLyTwBFfHX-XKcc&m=2ty5V_F2rdMdBJPJVLuXAmeH-EXUvcMMe-ug_QqIqZA&s=f7oVXD0X8QKcnInXVH2m-a2ddcj04_t-Qnwbj8dUwmA&e=>
>>>> 
>>>> 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 <mailto:llvm-dev at
lists.llvm.org>
>>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
<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
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20161027/00da606b/attachment.html>

Hi Mehdi, all!

Apologies for the delay, thanks for getting the conversation started!

(There was a death in my family last week, unfortunately)

I'm gathering these responses and ideas and will be replying in more
detail soon,
ideally we can converge on a candidate set of discussion points before
the BoF :).

On Mon, Oct 17, 2016 at 3:20 PM, Mehdi Amini <mehdi.amini at apple.com>
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”).
Absolutely! Getting a handle on the design space here would be great,
and I'm excited
to look at your flatbuffers prototype and results more carefully.
As you say, the way in which we store (and represent!) bitcode is an essential
part of a system like ALLVM or anything else with a persistent
representation of software as IR.

We have a prototype file format implementation and specification but
it's more of
a placeholder than a serious design yet.  Your experiments with bitcode
formats are extremely relevant to our interests :).
> 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.
>
Additional thoughts I've had on the subject, offhand:

* Hierarchical data-structures beyond modules
* Design of bitcode-based data-structures for multiple "similar"
versions of software
* Taking advantage of 'structure' of programs when viewed at a system
scale

In ALLVM all software is described as a composition of bitcode /fragments/
where fragments are intentionally vague for now but could be modules, functions,
traces, etc.

Identifying the best abstraction(s) to use here, and designing the
related algorithms
and data-structures for their construction/storage/analysis/transformation is
something we're hoping to address in the ALLVM project-- at the very least
to provide the means to evaluate candidate answers for real systems.

.. Anyway, I'm very interested in your ideas and would like to subscribe
to your newsletter. O:).
> —
> 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
>
>
>
>