similar to: Experiments with a replacement for the bitcode format

> On Sep 28, 2016, at 2:03 PM, Xinliang David Li <xinliangli at gmail.com> wrote: > > > > On Tue, Sep 27, 2016 at 12:56 PM, Mehdi Amini via llvm-dev <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: > Hello, > > Disclaimer: I have no plan to break 3.x bitcode compatibility in any way. > > I’m experimenting with ideas to

On Thu, Sep 8, 2016 at 11:34 PM Dean Michael Berris <dean.berris at gmail.com> wrote: > > > On 9 Sep 2016, at 12:35, Dean Michael Berris <dean.berris at gmail.com> > wrote: > > > > > > > >> On 7 Sep 2016, at 01:21, David Blaikie <dblaikie at gmail.com> wrote: > >> > >> But I take it you mean (as detailed later) to have a

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

On Mon, Jul 17, 2017 at 5:18 PM Mehdi AMINI <joker.eph at gmail.com> wrote: > 2017-07-17 16:49 GMT-07:00 David Blaikie via llvm-dev < > llvm-dev at lists.llvm.org>: > >> >> >> On Mon, Jul 17, 2017 at 6:11 AM Charles Saternos via llvm-dev < >> llvm-dev at lists.llvm.org> wrote: >> >>> Hey @chandlerc and @dblaikie, >>>

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

On Wed, Jul 19, 2017 at 8:43 AM Teresa Johnson <tejohnson at google.com> wrote: > On Wed, Jul 19, 2017 at 8:31 AM, David Blaikie <dblaikie at gmail.com> wrote: > >> >> >> On Mon, Jul 17, 2017 at 5:18 PM Mehdi AMINI <joker.eph at gmail.com> wrote: >> >>> 2017-07-17 16:49 GMT-07:00 David Blaikie via llvm-dev < >>> llvm-dev at

On Mon, Jul 17, 2017 at 6:11 AM Charles Saternos via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Hey @chandlerc and @dblaikie, > > Any updates on this in relation to "[PATCH] D34080: [ThinLTO] Add > dump-summary command to llvm-lto2 tool"? > Sorry you've kind of got stuck in the middle of this - but I'm still hoping to hear/understand the pushback on

On Dec 8, 2007, at 1:13 AM, Reid Spencer wrote: > Hi, > > I'm trying to separate the Support, System, ADT and Config header > files > into the support module, per previous plans. However, APFloat.h is not > self-contained: > > APFloat.h:105:43: error: llvm/Bitcode/SerializationFwd.h: No such file > or directory > APFloat.h:106:37: error:

> On 7 Sep 2016, at 01:21, David Blaikie <dblaikie at gmail.com> wrote: > > (sorry for the delay) > All good, thanks Dave! > On Tue, Aug 23, 2016 at 1:05 AM Dean Michael Berris <dean.berris at gmail.com <mailto:dean.berris at gmail.com>> wrote: > Hi llvm-dev, > > I've been implementing a tool for analysing XRay traces. A recap of XRay's

Hi Jan, > I've been looking into how to make llvm bitcode files smaller. There is one > simple change that appears to shrink linked bitcode files by about 15%. See > this spreadsheet for some rough data: > > https://docs.google.com/spreadsheet/ccc?key=0AjRrJHQc4_bddEtJdjdIek5fMDdIdFFIZldZXzdWa0E the improvement is wonderful! ... > In any case, the patch is attached if

Hi everyone, I want to use an LLVM new feature (llvm::orc::remote::RPCBase) to implement a simple RPC framework between two LLVM modules. It seems by this new class we can do serialization/deserialization on LLVM IR type system directly. But I haven't found any helpful stuff on google showing me how to use these RPC APIs. Can anyone give me some hints or example programs showing me how to use

Hi Ted, On Sat, 2007-12-08 at 06:59 -0800, Ted Kremenek wrote: > On Dec 8, 2007, at 1:13 AM, Reid Spencer wrote: > > > Hi, > > > > I'm trying to separate the Support, System, ADT and Config header > > files > > into the support module, per previous plans. However, APFloat.h is not > > self-contained: > > > > APFloat.h:105:43: error:

Hi all, I've been looking into how to make llvm bitcode files smaller. There is one simple change that appears to shrink linked bitcode files by about 15%. See this spreadsheet for some rough data: https://docs.google.com/spreadsheet/ccc?key=0AjRrJHQc4_bddEtJdjdIek5fMDdIdFFIZldZXzdWa0E The change is in how operand ids are encoded in bitcode files. Rather than use an "absolute

Hello, Are there any recipe to handle serialization / deserialization of external pointers. I'm thinking about something similar in spirit to the way we handle finalization of external pointers. Currently, if we create an external pointer, save the session, quit R, then load the session, we get a null pointer. One way I'm thinking of is to have an environment in the

Thanks all for your response. On Tue, May 29, 2018, at 5:38 PM, Duncan P. N. Exon Smith wrote: > > >> On May 29, 2018, at 12:55, Adrian Prantl <aprantl at apple.com> wrote: >> >> >> >>> On May 29, 2018, at 12:28 PM, David Blaikie <dblaikie at gmail.com> wrote: >>> >>> +some of the debug info cabal (& Duncan, as an

Ok, I'll submit a patch to turn that into a report_fatal_error saying you can't start an abbrev with an array or blob. Thanks, Filipe F On Fri, Jan 23, 2015 at 2:12 PM, Rafael Espíndola < rafael.espindola at gmail.com> wrote: > The restriction looks reasonable: A record starts with a code. The code > can be encoded as a literal or be part of the abbreviation. > >

Hi, I'm trying to separate the Support, System, ADT and Config header files into the support module, per previous plans. However, APFloat.h is not self-contained: APFloat.h:105:43: error: llvm/Bitcode/SerializationFwd.h: No such file or directory APFloat.h:106:37: error: llvm/CodeGen/ValueTypes.h: No such file or directory As you can see, APFloat.h depends on things that are not in the ADT,

Dear community, we are currently facing a problem related to the new type system in llvm 3.0. Our setting is the following: We have two or more modules, all in the same LLVMContext. They are sharing some types, meaning that for example functions in different modules are referencing the same (meaning pointer identical) type. Now we write the different modules to the disk, and read them back

While checking for serialization/deserialization without using pointee types, I've come across a few test cases that crash at head, without my debugging assertions for accessing pointee types. One of them is test/Transforms/StripSymbols/2010-06-30-StripDebug.ll Its retainedTypes metadata points to a metadata array of a single null element. This crashes the dyn_cast (because it's not a

Hi Lang, Thanks for your reply! It seems that the code of ORC has been changed a lot these months. Actually what I wanted to see then was quite simple, Let's say we have two modules M1.bc and M2.bc, and in M1 we want to call function foo(defined in M2.bc)with the function type int foo(float, char*){...} what basic steps do I need to do to make M1.bc call foo remotely? BTW, does the