search for: bitc

...rote: > > 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, >> >> As part of PR27551 I want to add a string table to the bitcode format to >> allow global value and comdat names to be shared with the proposed symbol >> table (and, as side effects, allow comdat names to be shared with value >> names, make bitcode files more compressible and make bitcode easier to >> parse). The format of the string...

Michael, Overall the code looks good. 80-cols: 2046 FMF.UnsafeAlgebra = 0 != (Record[OpNum] & (1 << bitc::FMF_UNSAFE_ALGEBRA)); 2047 FMF.NoNaNs = 0 != (Record[OpNum] & (1 << bitc::FMF_NO_NANS)); 2048 FMF.NoInfs = 0 != (Record[OpNum] & (1 << bitc::FMF_NO_INFS)); 2049 FMF.NoSignedZeros = 0 != (Record[OpNum] & (1 << bitc::FMF...

>>> Please add a generous block comment to >>> llvm/include/llvm/Bitcode/LLVMBitCodes.h above the new enum >>> explaining >>> what the difference is though. :) >> > > Should have said: > >> Should I take the same approach to the encoding of pointer types in >> the types table? PointerTypes are a bit easier. The code...

...;>>> >>>> <0002-Fast-math-flags-added-to-FPMathOperator.patch> >>>> <0003-Fast-math-interfaces-for-Instructions.patch> >>>> <0004-Fast-math-flags-for-LLVM-IR-parsing-and-printing.patch> >>>> <0005-Fast-math-flags-for-the-bitcode.patch> >>>> <0006-Fast-math-test-case-for-bitcode-and-textual-reading-.patch> >>>> <0007-Fast-math-optimization-fold-multiply-by-zero.patch> >>>> <0008-Fast-math-test-for-SimplifyInstruction-fold-multiply.patch> >>>> >>&...

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! ... > I...

...ething very strange going on with new users... i've created a new user using the smbldap-tools creation goes fine... smbldap-useradd -a -g labusers -G power_users -n -c 'test user' -m -P testuser I've set the password and i see this in my ldap dir: ldapsearch -x -D cn=ldapadmin,dc=bitc,dc=unh,dc=edu -W '(&(uid=testuser)(objectclass=SambaSamAccount))' # testuser, People, bitc.unh.edu dn: uid=testuser,ou=People,dc=bitc,dc=unh,dc=edu cn: testuser sn: testuser uid: testuser uidNumber: 2014 gidNumber: 100 loginShell: /bin/bash gecos: test user description: test user object...

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

I've just built samba debs from 2_2 head. looks like all is cool except pam_smbpass.so Jul 25 17:44:42 bitc passwd[18770]: PAM unable to dlopen(/lib/security/pam_smbpass.so) Jul 25 17:44:42 bitc passwd[18770]: PAM [dlerror: /lib/security/pam_smbpass.so: undefined symbol: ldap_value_free] Jul 25 17:44:42 bitc passwd[18770]: PAM adding faulty module: /lib/security/pam_smbpass.so ldd /lib/security/pam_smbp...

...n't >> involved >> addr spaces) and FUNC_CODE_INST_STORE2 (which can). The .bc >> writer can >> switch to unconditionally writing out stores in FUNC_CODE_INST_STORE2 >> format. >> >> Please add a generous block comment to >> llvm/include/llvm/Bitcode/LLVMBitCodes.h above the new enum >> explaining >> what the difference is though. :) > Should have said: > Should I take the same approach to the encoding of pointer types in > the types table? -- Christopher Lamb -------------- next part -------------- An HTML att...

...ModuleProvider interface. Overriding materializeFunction should be useful for on-demand instantiation. — Gordon On Mar 26, 2008, at 17:07, Jonathan S. Shapiro wrote: > Okay, we're starting to dig in, and I've hit a question that will no > doubt seem strange. > > Context: BitC is a polymorphic language. Since it has unboxed value > types, our approach to compiling a polymorphic function is to > polyinstantate it -- once for each signature. > > The name mangling scheme is both stable and reversible. At the site > of the use occurrence, we can fully de...

Okay, we're starting to dig in, and I've hit a question that will no doubt seem strange. Context: BitC is a polymorphic language. Since it has unboxed value types, our approach to compiling a polymorphic function is to polyinstantate it -- once for each signature. The name mangling scheme is both stable and reversible. At the site of the use occurrence, we can fully determine the mangled name of th...

...ounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Chris Lattner Sent: Sunday, November 25, 2007 2:08 PM To: LLVM Developers Mailing List Subject: Re: [LLVMdev] C embedded extensions and LLVM >>> Please add a generous block comment to >>> llvm/include/llvm/Bitcode/LLVMBitCodes.h above the new enum >>> explaining >>> what the difference is though. :) >> > > Should have said: > >> Should I take the same approach to the encoding of pointer types in >> the types table? PointerTypes are a bit easier. The code...

On May 6, 2008, at 11:49 PM, Jonathan S. Shapiro wrote: > On Tue, 2008-05-06 at 23:18 -0700, Chris Lattner wrote: >>> 1) Is there a way to declare an integer type in the IR that >>> represents >>> "an int the same size as a pointer" without specifying exactly the >>> size >>> of a pointer? >> >> No. > > Chris: > >

...ead both FUNC_CODE_INST_STORE (which can't involved > addr spaces) and FUNC_CODE_INST_STORE2 (which can). The .bc writer > can > switch to unconditionally writing out stores in FUNC_CODE_INST_STORE2 > format. > > Please add a generous block comment to > llvm/include/llvm/Bitcode/LLVMBitCodes.h above the new enum explaining > what the difference is though. :) Should I take the same approach to the encoding of pointer types in the pointer table? -- Christopher Lamb -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.l...

On Tue, 2008-05-06 at 23:18 -0700, Chris Lattner wrote: > > 1) Is there a way to declare an integer type in the IR that represents > > "an int the same size as a pointer" without specifying exactly the > > size > > of a pointer? > > No. Chris: There are other languages that specify a "word" type along these lines. Would it be worth considering

Hi, On Sat, Oct 31, 2009 at 11:42 AM, Nan Zhu <zhunansjtu at gmail.com> wrote: > Hi,all > > I tried to run the generated whole-program bitcode of BIND,but I got some > information: > > 0   lli             0x0000000000feda16 > 1   lli             0x0000000000fed88f > 2   libpthread.so.0 0x0000003df340eee0 > 3   libc.so.6       0x0000003df28332f5 gsignal + 53 > 4   libc.so.6       0x0000003df2834b20 abort + 384 >...

Mahadevan R wrote: > Hi, > > On Sat, Oct 31, 2009 at 11:42 AM, Nan Zhu <zhunansjtu at gmail.com> wrote: >> Hi,all >> >> I tried to run the generated whole-program bitcode of BIND,but I got some >> information: >> >> 0 lli 0x0000000000feda16 >> 1 lli 0x0000000000fed88f >> 2 libpthread.so.0 0x0000003df340eee0 >> 3 libc.so.6 0x0000003df28332f5 gsignal + 53 >> 4 libc.so.6 0x000000...

...that the technique we are after is generally useful for languages having well-integrated template mechanisms. The approach you advocate may still be the best approach, but I'ld like to make sure that we are having the same conversation. Let me illustrate the problem concretely. Consider the BitC primitive definition of lists: (defunion (list 'a) (cons 'a (list 'a)) nil) Modulo surface syntax, this looks on first inspection to be exactly like the corresponding definitions in ML or Haskell. But in ML or Haskell there is only one run-time "expansion" of this...

...d an intptr type. The semantics I would imagine for an intptr type are: • Lowered to i32 or i64 for code generation. • Treated an ordinary integer for all operations except casts. • Can be the operand to ptrtoint, but not the result. • Can be the result of inttoptr, but not the operand. • Can be bitcast to an actual pointer type. • Whether sext, zext, and trunc are applicable, I could be convinced either way. It muddies the semantics of these operations. On 2008-05-07, at 12:51, Mike Stump wrote: > The word opaque comes to mind. The basic question is, do you want > people to be abl...

This is not, strictly speaking, an LLVM issue, but it is an implementation matter that a compiler using LLVM needs to handle. I've got resolutions for other platforms, but I'm not seeing how to get this done for PowerPC, and I'ld appreciate suggestions or pointers. For BitC procedures that require an environment pointer, our general approach has been to construct a heap-allocated assembly code fragment. This fragment operates as follows: loads the environment pointer into a register that is call clobbered but not perturbed by the preamble. branches to a st...