similar to: [LLVMdev] PPC calling convention -- how to provide an environment pointer?

> Message: 5 > Date: Mon, 26 Jan 2009 21:47:12 -0500 > From: "Jonathan S. Shapiro" <shap at eros-os.com> > Subject: [LLVMdev] PPC calling convention -- how to provide an > environment pointer? > To: LLVM Developers Mailing List <llvmdev at cs.uiuc.edu> > Message-ID: <1233024432.24380.11.camel at vmx> > Content-Type: text/plain > > This is

On Tue, 2009-01-27 at 08:59 -0800, Stuart Hastings wrote: > I assume you're talking about the 32-bit PowerPC. Also 64-bit, but the two register usage conventions are very close. Someone previously pointed out that R0 is usable as a scratch register, and the CTR can be used. CTR *must* be used for the branch destination out of the ASM trampoline. R0 ends up getting used a lot for constant

> Message: 8 > Date: Tue, 27 Jan 2009 18:00:26 -0500 > From: "Jonathan S. Shapiro" <shap at eros-os.com> > Subject: Re: [LLVMdev] PPC calling convention -- how to provide an > environment pointer? > To: LLVM Developers Mailing List <llvmdev at cs.uiuc.edu> > Message-ID: <1233097226.27873.11.camel at vmx> > Content-Type: text/plain > > On

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

Hi Jonathan, In the context of a static compiler, I would recommend that you implement your own “on the side” symbol table in order to track this state and perform on-demand instantiation as required. It is worthwhile to consider the LLVM module to be a passive output sink, not an active object. The JIT compiler, by contrast, is an active object, cooperating with its environment via

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

On Thu, 2008-03-27 at 07:44 -0400, Gordon Henriksen wrote: > In the context of a static compiler, I would recommend that you > implement your own “on the side” symbol table in order to track this > state and perform on-demand instantiation as required. It is > worthwhile to consider the LLVM module to be a passive output sink, > not an active object. I think I understand what you

>>> 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 to write them

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

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

On Wed, 2008-05-07 at 13:24 -0700, Chris Lattner wrote: > Querying TargetData only works if you know the size of the pointer. :) Yes. For BitC purposes, querying TargetData would be sufficient as long as we don't care whether the emitted IR is neutral w.r.t. pointer size. Given this, I think that introducing an iWord type is not yet sufficiently well motivated from the BitC perspective.

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 >

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

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

On 2008-05-07, at 03:05, Chris Lattner wrote: > On May 6, 2008, at 11:49 PM, Jonathan S. Shapiro wrote: > >> There are other languages that specify a "word" type along these >> lines. Would it be worth considering adding such a type to the IR, >> or is there a reason not to do so that I am failing to see? > > What would this be used for? How is it

On Thu, 2008-03-27 at 21:39 +0200, Pertti Kellomäki wrote: > Except that some aspects of the host platform leak through > to .bc files. This may or may not be a problem. A question about this occurred to me last night. BitC has only one machine-dependent type: word. The current runtime.h file typedef's this in a machine-dependent way, but all of the C code emitted by our current back

I was re-reading the specification for extractelement and friends, and I notice that the index is restricted to i32. Since vectors might clearly have a larger number of elements on 64-bit platforms, I wonder if I am misunderstanding the intended use of these instructions. Is this indeed intended for vector and structure access in general, or is intended to support (only) more specialized SIMD

On Mon, 2008-09-29 at 09:50 +0200, Duncan Sands wrote: > For the moment, yes. If unwind gets implemented one day (I have a plan, > but no time right now), the implementation is sure to call routines in > the gcc runtime. As a transient solution that makes sense, but it seems desirable to have a generalized unwind scheme that is not tied to libgcc. shap