similar to: [LLVMdev] Reloading Function from a bitcode file.

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

+llvmdev > On 2014 Dec 18, at 15:14, Rafael Espíndola <rafael.espindola at gmail.com> wrote: > > Currently we support reading bitcode in 3 ways: > > * Read everything upfront. > * Be lazy about reading the function bodies. > * Read the bitcode over a streaming interface. > > The first two modes are commonly used and well tested. In fact the > "read

>> Apparently BitcodeReader.h is only in lib/Bitcode/Reader/ but not in >> include, so a make install does not install it. >I'm not sure what you mean... the header is in include/llvm/Bitcode. >> Is it supposed to be accessible from applications? How exactly? I feel that >> some install rule is missing; after a sudo make install, >> grep -rn BitcodeReader

Hello, Chris's "keynote" at the LLVM Developers' Conference included a call for code owners, and my company has a heavy dependency on Bitcode, I propose taking ownership of: lib/Bitcode/* include/Bitcode/* This means that I'll be committed to documenting (yay) the implementation and responsible for reviewing patches and commits, as well as overall code quality and

> On Oct 25, 2016, at 6:28 PM, Peter Collingbourne <peter at pcc.me.uk> wrote: > > Hi all, > > As mentioned in my recent RFC entitled "RFC: a more detailed design for ThinLTO + vcall CFI" I would like to introduce the ability for bitcode files to contain multiple modules. In https://reviews.llvm.org/D24786 <https://reviews.llvm.org/D24786> I took a step

Le Sat, May 12, 2007 at 04:42:49PM -0700, Chris Lattner écrivait/wrote: > On Sat, 12 May 2007, Basile STARYNKEVITCH wrote: > > with the latest LLVM (almost 2.0 CVS) what is the right way to read a module > > from a byte array fetched from a database? > > The bitcode reader will read from any MemoryBuffer object. There are a > variety of static methods on MemoryBuffer to

Hi all, As mentioned in my recent RFC entitled "RFC: a more detailed design for ThinLTO + vcall CFI" I would like to introduce the ability for bitcode files to contain multiple modules. In https://reviews.llvm.org/D24786 I took a step towards that by proposing a change to the module format so that the block info block is stored at the top level. The next step is to think about what the

Hi Joe, > We have a tool which reads in bitcode, processes it, and re-emits it. We use > this tool as a flexible way to integrate our tool into the Xcode, Android NDK, > Chromium, and Linux build process. > > The problem we face is that bitcode changes, and when it does… future versions > can read it, but past versions are left in the lurch. For instance LLVM 3.2svn > can

On Nov 10, 2012, at 10:43 AM, Joe Abbey <jabbey at arxan.com> wrote: > Hello, > > Chris's "keynote" at the LLVM Developers' Conference included a call for code owners, and my company has a heavy dependency on Bitcode, I propose taking ownership of: > > lib/Bitcode/* > include/Bitcode/* > > This means that I'll be committed to documenting

Hello, We have a tool which reads in bitcode, processes it, and re-emits it. We use this tool as a flexible way to integrate our tool into the Xcode, Android NDK, Chromium, and Linux build process. The problem we face is that bitcode changes, and when it does… future versions can read it, but past versions are left in the lurch. For instance LLVM 3.2svn can BitcodeReader from LLVM 3.1, but

On Nov 8, 2012, at 3:31 AM, Duncan Sands <baldrick at free.fr> wrote: > Hi Joe, > >> We have a tool which reads in bitcode, processes it, and re-emits it. We use >> this tool as a flexible way to integrate our tool into the Xcode, Android NDK, >> Chromium, and Linux build process. >> >> The problem we face is that bitcode changes, and when it does…

On Nov 8, 2012, at 7:09 AM, Joe Abbey <jabbey at arxan.com> wrote: >>> The problem we face is that bitcode changes, and when it does… future versions >>> can read it, but past versions are left in the lurch. For instance LLVM 3.2svn >>> can BitcodeReader from LLVM 3.1, but LLVM 3.1 can't BitcodeReader LLVM 3.2 >>> (after r165739.) There was an

On Wed, Oct 26, 2016 at 2:04 PM, Peter Collingbourne via llvm-dev <llvm-dev at lists.llvm.org> wrote: > On Tue, Oct 25, 2016 at 8:36 PM, Mehdi Amini <mehdi.amini at apple.com> wrote: >> >> >> On Oct 25, 2016, at 6:28 PM, Peter Collingbourne <peter at pcc.me.uk> wrote: >> >> Hi all, >> >> As mentioned in my recent RFC entitled

On Tue, Oct 25, 2016 at 8:36 PM, Mehdi Amini <mehdi.amini at apple.com> wrote: > > On Oct 25, 2016, at 6:28 PM, Peter Collingbourne <peter at pcc.me.uk> wrote: > > Hi all, > > As mentioned in my recent RFC entitled "RFC: a more detailed design for > ThinLTO + vcall CFI" I would like to introduce the ability for bitcode > files to contain multiple

On Sat, 12 May 2007, Basile STARYNKEVITCH wrote: > with the latest LLVM (almost 2.0 CVS) what is the right way to read a module > from a byte array fetched from a database? The bitcode reader will read from any MemoryBuffer object. There are a variety of static methods on MemoryBuffer to create them from files, stdio, and memory. If your buffer is in memory, just create a memorybuffer

> On Oct 28, 2016, at 2:21 PM, Mehdi Amini via llvm-dev <llvm-dev at lists.llvm.org> wrote: > >> >> On Oct 28, 2016, at 2:16 PM, Will Dietz <willdtz at gmail.com <mailto:willdtz at gmail.com>> wrote: >> >> On Fri, Oct 28, 2016 at 2:06 PM, Peter Collingbourne <peter at pcc.me.uk <mailto:peter at pcc.me.uk>> wrote: >>> On Fri,

Hi all, We've run into a tricky situation in our work on the Crack compiler and I'm hoping that someone on this list can help us find the best solution. We're currently trying to implement "module caching" for Crack, similar to the feature in Python where module bitcode is persisted at compile time. When we import a module, before compiling the module we check for a

On Fri, Oct 28, 2016 at 2:06 PM, Peter Collingbourne <peter at pcc.me.uk> wrote: > On Fri, Oct 28, 2016 at 6:11 AM, Will Dietz <willdtz at gmail.com> wrote: >> >> On Wed, Oct 26, 2016 at 2:04 PM, Peter Collingbourne via llvm-dev >> <llvm-dev at lists.llvm.org> wrote: >> > On Tue, Oct 25, 2016 at 8:36 PM, Mehdi Amini <mehdi.amini at apple.com>

Sent from my iPhone On Nov 9, 2012, at 4:55 PM, "Chris Lattner" <clattner at apple.com> wrote: > On Nov 8, 2012, at 7:09 AM, Joe Abbey <jabbey at arxan.com> wrote: >>>> The problem we face is that bitcode changes, and when it does… future versions >>>> can read it, but past versions are left in the lurch. For instance LLVM 3.2svn >>>>

Hello, with the latest LLVM (almost 2.0 CVS) what is the right way to read a module from a byte array fetched from a database? I thought that I could subclass llbm::module to add my own fields (typically, a MySQL id number) and then parse it as bitcode, but I am stuck, since apparently the only way to parse bitcode is to use a BitcodeReader then calling materializeModule gives a fresh llvm