similar to: [LLVMdev] JIT and anonymous procs

On Wed, 2008-03-26 at 10:40 -0700, Chris Lattner wrote: > On Wed, 26 Mar 2008, Jonathan S. Shapiro wrote: > > The Kaleidoscope tutorial has us "interpreting" top-level expressions by > > generating a one-shot anonymous procedure and executing that. Once the > > expressions have been executed, these procedures will never be called > > again. > > > >

On Wed, 26 Mar 2008, Jonathan S. Shapiro wrote: > The Kaleidoscope tutorial has us "interpreting" top-level expressions by > generating a one-shot anonymous procedure and executing that. Once the > expressions have been executed, these procedures will never be called > again. > > How can the associated storage for this anonymous procedure be > reclaimed? All

On Wed, Mar 26, 2008 at 2:01 PM, Jonathan S. Shapiro <shap at eros-os.com> wrote: > > All functions in the tutorial are referenced by their Function*. The > > Function* uniquely identifies a function and is independent of the name. > > I had understood that. > > So now I have compiled and run my top level expression's anonymous > function. How do I go

On Wed, 2008-03-26 at 23:48 +0100, Óscar Fuentes wrote: > "Jonathan S. Shapiro" <shap at eros-os.com> writes: > My front-end is very similar to yours in the feature of the multiple > instantiations on demand, etc. Oscar: after you have a chance to read my recent reply to Gordon, would you be kind enough to let me know whether you still believe the situations are similar.

In the course of applying Shapiro-Wilk to 100,000 samples of 60 items from 100,000 different distributions, I encountered a fatal error in apply(). This can be reconstructed as follows, using the attached data file distr.dat containing 2 lines of my original 100,000-line file: > version _ platform Windows arch x86 os Win32 system x86, Win32 status

Hi, I am trying to create a table with information from Shapiro Wilk's test of normality. However, it fails due to lack of sample size, it says, but the way I see it, this is not a problem. (See the table of sample sizes (almost) at the bottom). Applying a different function using a similar ftable call is not a problem (See the bottom table). This is R 2.1.0 on Linux (Gentoo). /Fredrik

"Jonathan S. Shapiro" <shap at eros-os.com> writes: [snip] > 4. Is there a better/cleaner approach? What other options should I > consider? My front-end is very similar to yours in the feature of the multiple instantiations on demand, etc. One thing I learnt about LLVM is that it's philosophy is to be a friendly backend for frontends, but whatever your frontend

In alloca, is it required that NumElements be a literal integer, or can it be a computed result? The real question is whether the current IR can support a one-stack implementation of Ada's dynamically sized stack frames. shap

On Thu, 2008-05-01 at 12:00 -0500, David Greene wrote: > On Wednesday 30 April 2008 21:21, Chris Lattner wrote: > > > If LLVM is able to eliminate all users of the malloc assuming the > > malloc succeeded (as in this case), then it is safe to assume the malloc > > returned success. > > Ah, I missed this bit. I didn't see that the result of malloc was not used

I have a client who might well make use of an AVR32 port, but I suspect that machine is very different than the one you are currently examining. shap On Mon, 2008-05-19 at 12:38 -0600, John Regehr wrote: > Anyone else interested in an AVR backend? > > If so, for what members of the AVR family? If we do a port, likely it'll > support only the ATmegas. > > John >

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

On Thu, 2008-03-27 at 21:22 +0100, Óscar Fuentes wrote: > I'm all for hooks and delegation, but the problem here is that your > proposal is not general enough and is hard to generalize it. It does not > work for my project, for instance, although I face almost the same > requirements than you wrt dynamic generation. The symbol name is enough > for you, but not for me, and there

On Tue, 2008-05-13 at 23:36 -0700, Chris Lattner wrote: > I don't want to discourage you, but you are basically asking for > interpretation of legal documents... > If you really really need to know the answer to questions like these, > the best bet is to hire legal council. Chris is right. I would add that it sounds like you are already getting nonsense responses. However,

On Mon, 2008-08-11 at 16:09 +0300, Valen wrote: > Hi, > Im trying to generate C source from C++ source file, > using C backend. > > llvm-g++ -O3 -emit-llvm valen.cpp -c -o valen.bc > llc -march=c valen.bc -f -o valen.c > > > But C backend generate a lot of operation with "long long" type. > My C compiler does not support "long

On Sun, 2008-09-21 at 11:16 -0700, Chris Lattner wrote: > Thanks for working on this Óscar! >From me as well. In fact, your success at this has me looking again at CMake for some other things as well. shap

Alex: I'm not sure you're taking the right approach with this. You can either have portability or you can play games with the calling convention assumed by the back end, or you can modify the compiler to suit your desired calling convention, but you probably can't get all three. I'm the guy behind HDTrans (dynamic binrary translation for x86), and we used direct x86 instruction

> 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

Watching this thread, it occurs to me that the "V" in "LLVM" is creating confusion. So far as I know, LLVM is the first project to use "virtual" to refer to the instruction set of the intermediate form. I understand why this labeling made sense (sort of), but it was unfortunate. The machine is abstract, not virtual, and the use of "virtual" here is so out of

In general, it is not possible to know jitted code size without emitting. You can suppress the actual write of the instructions themselves, but you have to do all of the work prior to that point. The reason is that on many architectures there are span-dependent branches. The final instruction size depends on the branch span. The span depends on the code size, and the code size depends on the

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