search for: instids

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

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

> On 2014-Jul-08, at 16:48, Chandler Carruth <chandlerc at google.com> wrote: > > >> On Tue, Jul 8, 2014 at 4:29 PM, Duncan P. N. Exon Smith <duncan at exonsmith.com> wrote: >> I'm looking to tackle PR5680 [1]. The primary goal is to prevent >> behaviour changes in passes that depend on the order of use lists when >> serializing/deserializing the

...However, we need an ordering for all > users. > > Fortunately, when processing each function, all instructions are given > an instruction ID. We could modify `compareUsers()` above to take a > function `getUserID()` written something like this: > > auto getUserID = [&InstIDs, &IDs](User *U) { > if (unsigned ID = InstIDs.lookup(U)) > return IDs.size() + ID; > return IDs.lookup(U); > }; > auto compareUsers = [&getUserID](User *LHS, User *RHS) { /* ... */ } > > Constant forward-refs > --------------------...

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

Hi everyone, I am trying to calculate a particular variable (vector) from some previously defined variables in a loop but I am having trouble figuring out how to get the loop to recognize that it should index for the previously defined objects. Here is a simplified version of what I am trying to do: for(i in 1:10){

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

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

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

Hi all, The C++11 (& C11) compare_exchange functions with explicit memory order allow you to specify two sets of semantics, one for when the exchange actually happens and one for when it fails. Unfortunately, at the moment the LLVM IR "cmpxchg" instruction only has one ordering, which means we get sub-optimal codegen. This probably affects all architectures which use