similar to: [LLVMdev] [PATCH / PROPOSAL] bitcode encoding that is ~15% smaller for large bitcode files...

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 all, I have a question with the "getelemptr" instruction. E.g.: I have some GEP instructions in my program. Some look like: <INST_GEP op0=26 op1=64 op2=429/> . <INST_GEP op0=341 op1=64 op2=101 op3=499 op4=0/> The first instruction above in assembly file: %tmp60 = getelementptr [512 x i32]* @weights, i32 0, i32 %k.3.ph Ok, we see it all: Index of @weights in value

Moving to LLVM dev to discuss the possibility of extending the cast infrastructure to handle this. On Tue, Nov 20, 2012 at 5:51 PM, John McCall <rjmccall at apple.com> wrote: > On Nov 18, 2012, at 5:05 PM, David Blaikie <dblaikie at gmail.com> wrote: >> TypeLoc casting looks bogus. >> >> TypeLoc derived types return true from classof when the dynamic type >>

Dear Patrice, I have noticed that you are referencing to the Stahnma repository for Spacewalk Client Tools. These are quite old and I would suggest to use the tools from: http://spacewalk.redhat.com/yum instead. Mr. Suchy already pushed some of the packages to Fedora/EPEL so they might be available there, soon. Besides that the Spacewalk Team is thinking about a split between client/server on

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

I have a question about module-level METADATA_BLOCKs in the bitcode. There are currently two blocks with the METADATA_BLOCK id at module scope. The first has the module-level metadata values (consisting of some combination of METADATA_* record codes except for METADATA_KIND). The second consists only of METADATA_KIND records. The latter is used only in the METADATA_ATTACHMENT block within function

> On 2016-Apr-21, at 11:41, Mehdi Amini <mehdi.amini at apple.com> wrote: > > >> On Apr 21, 2016, at 11:25 AM, Teresa Johnson <tejohnson at google.com> wrote: >> >> I am currently making some BitcodeWriter changes that involve some refactoring, and am thinking for the Nth time that it would be much nicer to have a class instead of passing around a long

On Thu, 21 Jun 2001 20:53:30 +0200, Flo <sherpac@gmx.de> wrote: > >DdeInitialize(InstId, (PFNCALLBACK)(FARPROC) >CallBackProc, APPCMD_CLIENTONLY, 0) == DMLERR_NO_ERROR, file >..\dde\MyDDE.cpp, >line 238 > >happens after the following cmd line (wine) message: > >fixme:ddeml:DdeConnect (0x1,49180,49181,(nil)): stub > > >The application may try to run MSIE

Hi, I am trying to generate LLVM bytecode using CLANG and I ran into the following problem. If I run clang with the -emit-llvm option and then try to get a textual representation of the output using llvm-dis, the latter crashes because of a failed assertion in BitCodeReader.cpp, mentioning a "Type mismatch in value table" (the exact error message is appended at the end of this email).

On Nov 14, 2012, at 12:47 PM, Chris Lattner <clattner at apple.com> wrote: > > On Nov 14, 2012, at 12:28 PM, Michael Ilseman <milseman at apple.com> wrote: > >> I think I missed what problem we're trying to solve here. >> >> I'm looking at implementing the bitcode now. I have code to successfully read and write out the LLVM IR textual formal

On Sep 25, 2012, at 5:08 PM, Jan Voung <jvoung at chromium.org> wrote: > 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

On Thu, Nov 29, 2012 at 3:49 PM, David Blaikie <dblaikie at gmail.com> wrote: > Moving to LLVM dev to discuss the possibility of extending the cast > infrastructure to handle this. > > On Tue, Nov 20, 2012 at 5:51 PM, John McCall <rjmccall at apple.com> wrote: >> On Nov 18, 2012, at 5:05 PM, David Blaikie <dblaikie at gmail.com> wrote: >>> TypeLoc

Hi, For the first problem, try clang -S -emit-llvm test.c -o test.ll you should get the llvm IR and you don't need to use llvm-dis. Although I have tried your example with the exact commands and source code you posted and it worked just fine for me. I also use clang and LLVM 2.8 compiled from sources. For the second problem, suppress -emit-llvm, since you want the executable, not an object

A while back I finished up some work [1] that Chad started to preserve use-list-order in bitcode [2], hidden behind an "experimental" option called `-preserve-bc-use-list-order`. I then added a similar `-preserve-ll-use-list-order` option for LLVM assembly [3]. [1]: http://lists.cs.uiuc.edu/pipermail/llvmdev/2014-July/074604.html [2]: https://llvm.org/bugs/show_bug.cgi?id=5680 [3]:

I am currently making some BitcodeWriter changes that involve some refactoring, and am thinking for the Nth time that it would be much nicer to have a class instead of passing around a long list of parameters. I am thinking of biting the bullet and doing that - any objections? I assume the reason why there is no existing class wrapping the bitcode writing process is just legacy code and nothing

I had a long discussion with Nick about this where he changed several of my core assumptions and feelings about the best way to proceed here. I'd rather he provide his perspective rather me try to repeat it, so poking him on this thread.... On Sun, Jul 20, 2014 at 3:21 PM, Duncan P. N. Exon Smith < dexonsmith at apple.com> wrote: > > > On 2014 Jul 8, at 18:47, Duncan P. N.

I've attached a preliminary patch for `MDLocation` as a follow-up to the RFC [1] last week. It's not commit-ready -- in particular, it squashes a bunch of commits together and doesn't pass `make check` -- but I think it's close enough to indicate the direction and work toward consensus. [1]: http://lists.cs.uiuc.edu/pipermail/llvmdev/2014-October/077715.html IMO, the files to

Hi there, I added a function to a module, but failed to write the bitcode to file because it hit the: assert(I != ValueMap.end() && "Value not in slotcalculator!") So I added some diagnosis information there, unsigned ValueEnumerator::getValueID(const Value *V) const { if (isa<MDNode>(V) || isa<MDString>(V)) { ValueMapType::const_iterator I =

Hi Guoliang, > I added a function to a module, but failed to write the bitcode to file > because it hit the: > assert(I != ValueMap.end()&& "Value not in slotcalculator!") does the module pass the verifier after you add the function to it? Ciao, Duncan.

Hi, I'm trying to replace pointer typed alloca instructions to allocate a vector of pointers. The idea is to change from [1] to [2]: [1]: %0 = alloca i<N>* [2]: %0 = alloca <3 x i8*> I did it this way: - first, create and insert [2] (for debug purpose, not necessary to insert) - mutate type so that replaceAllUsesWith can be called in a correctly typed way - replace all