similar to: [LLVMdev] Misunderstanding vector

On Sunday 21 September 2008 20:45:37 Jonathan S. Shapiro wrote: > 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. The code generator cannot handle vectors

On Mon, 2008-09-22 at 09:42 +0200, Duncan Sands wrote: > On Sunday 21 September 2008 20:45:37 Jonathan S. Shapiro wrote: > > 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

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

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

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.

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.

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

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

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

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

"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

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 >

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

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

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

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

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