similar to: [LLVMdev] Question concerning alloca

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, This is quite a simple question so hopefully it's easy to answer. I was looking at the documentation for the alloca instruction ( http://llvm.org/docs/LangRef.html#alloca-instruction ) and something is unclear to me. The given syntax is... <result> = alloca <type>[, <ty> <NumElements>][, align <alignment>] ; yields {type*}:result And the documentation

"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

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

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

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

Thanks for the reply. Please see my inline responses. On 15/08/13 12:58, Tim Northover wrote: > Hi Dan, > >> It is not stated how the "<ty>" type is used as we are told the >> type of result is type* and sizeof(<type>)*NumElements is the >> amount of memory so from my perspective it looks like <ty> is >> never used which would seem to

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

And the code of the Linux kernel compiled by LLVM is also very arch depended, despite any loader and hw access will not work inside the standard LLVM JIT, all the MMU and low-level access stuff will make no sense on a machine other than what was enabled while compiling the kernel. E.g. you would need a whole virtualized HW architecture ala Qemu (et al.) along the JIT. Of course in theory one

The discussion of malloc optimization from two (three?) weeks ago prompts me to be concerned about implications for kernel compilation. Basically, I have two questions: 1. The particular optimization that was done there was based on the compiler substituting an alternate implementation of malloc(). This may not be appropriate in kernel or deeply embedded systems. Is there a way for someone who is

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 long" type. Is there any option to disable generate "long long" ? -- Thanks,

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

If <NumElements> is zero, what is the behavior of malloc() and alloca()? Can I call free() using the pointer that malloc() returns? Also, I'm assuming that free()ing a null pointer is a legal NOP? Regards, Jon

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