similar to: RFC: APIs for bitcode files containing multiple modules

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

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> > wrote: > >> > >> > >> On Oct 25, 2016, at 6:28 PM, Peter Collingbourne <peter

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

> On Oct 28, 2016, at 2:16 PM, Will Dietz <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, 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

> 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,

On Tue, Apr 4, 2017 at 12:36 PM, Duncan P. N. Exon Smith < dexonsmith at apple.com> wrote: > > On 2017-Apr-04, at 12:12, Peter Collingbourne <peter at pcc.me.uk> wrote: > > On Mon, Apr 3, 2017 at 8:13 PM, Mehdi Amini <mehdi.amini at apple.com> wrote: > >> >> On Apr 3, 2017, at 7:08 PM, Peter Collingbourne <peter at pcc.me.uk> wrote: >>

Hey there, I'm relatively new to the llvm scene, and so far I'm liking it quite a bit. I'm a bit perplexed as to what llvm-gcc's role is in everything. I've used it to create .bc files for really simple functions and it seems to do quite well at that, but I've been trying to figure out how to take the output from llvm-gcc and actually use it in another program.

Hi Danny, On 2007-12-26, at 15:39, Danny wrote: > I've noticed that the BitcodeReader appears to be an internal > module, but the BitstreamReader is public. Should I be using the > BitstreamReader? If so how. The generic BitstreamReader class is public because it's used in other projects, including clang, to serialize data structures other than LLVM IR. The coding of

That worked quite well. Thank you. One question as a follow up: is there a nice/standard way of including the pre-made bitcode chunks in with the binaries that are being created which read them? Bascially, I'd like to have the same functionality, but rather than having one or more .bc files running around which need to be read at runtime by an executable, moving that into the code

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

> > I also have a look at the code, looks like it directly parse the bitcode > and build in memory representation in a different LLVM version than the > bitcode. Is this correct? According to your description, I guess the BitCodeWriter should be the one > to do the bitcode version downgrade, right? I think so. I don't know much about it and don't want to give you

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

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 Duncan, On 5/6/12 6:12 PM, Duncan Sands wrote: > Hi Ralf, > >> Is there a clean way to attach metadata nodes to Arguments and/or >> BasicBlocks? > > not at the moment. Feel free to work on adding this functionality! I am looking into that now. I decided to temporarily go for the following syntax for BasicBlock metadata (subject to discussion): entry:

Thanks Steve and Mehdi for the explanation. Steve, I am a little be confused by looking at the code in https://android.googlesource.com/platform/frameworks/compile/libbcc/+/master/bcinfo/BitReader_3_0/BitcodeReader.cpp. Looks like the BitcodeReader do some translation while reading the bitcode. If LLVM ToT can read the bitcode of LLVM 3.0, while can't we just use the bitcode reader in LLVM

Hi Steve, Several people told me that LLVM TOT bcreader can read odder version of bitcode without any problem. Do you know the oldest version of bitcode that the TOT bitcode reader supports? Also, why do you generate bitcode instead of the textural representation, i.e. the "ll" file, for older version of LLVM? I guess generating "ll" code is simpler. Another approach I am

> On Aug 2, 2016, at 8:49 PM, Stephen Hines <srhines at google.com> wrote: > > > > On Tue, Aug 2, 2016 at 8:44 PM, Mehdi Amini <mehdi.amini at apple.com <mailto:mehdi.amini at apple.com>> wrote: > >> On Aug 2, 2016, at 8:38 PM, Stephen Hines via llvm-dev <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: >>

Hi mailing list, I has been working on a large project that is based on LLVM 3.1. Recently we are thinking to introduce an LLVM bc converter from LLVM 3.9 to LLVM 3.1, such that we can introduce some of the newest LLVM analyses and optimizations to our LLVM 3.1 based project. Have you worked on similar things that converting LLVM bc downward and has anything to share? Thanks Hongbin