similar to: [LLVMdev] Arbitrary bit width integers

Sandro Magi wrote: >Where does the storage for large bit width integers come from? Are >very large numbers heap allocated? > > The ConstantInt class stores integer values. Large or not they are stored using an APInt object. APInt (lib/Support/APInt.cpp) uses an array of uint64_t if more than two are needed or an inline uint64_t in the APInt object. So, yes, they are heap

Ok, so if I needed very precise control over the allocation of memory, then I should avoid using integers with bit widths larger than 64 bits (or perhaps 128)? Is there a hard rule for an integer being stack allocated, ie. one that doesn't depend on the current implementation details? Sandro On 6/18/07, Reid Spencer <rspencer at reidspencer.com> wrote: > Sandro Magi wrote: > >

On Mon, 18 Jun 2007, Sandro Magi wrote: > Ok, so if I needed very precise control over the allocation of memory, > then I should avoid using integers with bit widths larger than 64 bits > (or perhaps 128)? Is there a hard rule for an integer being stack > allocated, ie. one that doesn't depend on the current implementation > details? In the generated code, or in the compiler

On 6/18/07, Chris Lattner <sabre at nondot.org> wrote: > On Mon, 18 Jun 2007, Sandro Magi wrote: > > Ok, so if I needed very precise control over the allocation of memory, > > then I should avoid using integers with bit widths larger than 64 bits > > (or perhaps 128)? Is there a hard rule for an integer being stack > > allocated, ie. one that doesn't depend on

On Mon, 18 Jun 2007, Sandro Magi wrote: > Generated code. So the memory used for the integer at program runtime > is inlined into the allocation point then? So if I define a local > variable of type 'i1024', it will allocate a block of 1024 bits on the > stack, if I define a struct with an i1024, it will be in the struct > itself, etc. Yes, exactly. > Is there anyone

Chris Lattner wrote: >On Mon, 18 Jun 2007, Sandro Magi wrote: > > >>Generated code. So the memory used for the integer at program runtime >>is inlined into the allocation point then? So if I define a local >>variable of type 'i1024', it will allocate a block of 1024 bits on the >>stack, if I define a struct with an i1024, it will be in the struct

Given my recent posts, I think it's obvious that I'm trying to figure out how to build a resource-aware VM for a high-level language. I've figured out adequate solutions for most of the problems I've encountered, including separate heaps, quotas, etc. However, I'm not sure how I can account for a thread's stack space. Given a language process (LP) running in a heap with a

On Wed, 20 Jun 2007, Sandro Magi wrote: > To this end, are there any implicit allocations being done by > generated LLVM code, other than the system stack? heap allocations? Only malloc/free. Note that the compiler does generate calls to runtime libraries (e.g. libstdc++ and libgcc), we don't have control over when they do allocations. The libstdc++ calls show up in the .ll file,

Sorry, clicked send by accident. It seems there's some background I'm missing though. Can I read up on this "as-if" rule anywhere? I was just saying this translation seems safe for word-sized or smaller objects, since those could end up being allocated to registers and such. My confusion is over larger object sizes. At what point would the translation not be done, or would it

To this end, are there any implicit allocations being done by generated LLVM code, other than the system stack? Sandro On 6/18/07, Sandro Magi <naasking at gmail.com> wrote: > Given my recent posts, I think it's obvious that I'm trying to figure > out how to build a resource-aware VM for a high-level language. > > I've figured out adequate solutions for most of the

On Thu, 1 May 2008, Sandro Magi 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. > > I don't see how this could be true in general, without either > knowledge of the malloc implementation, which would be fine, or > presuming knowledge of

On Thu, May 1, 2008 at 6:54 PM, Chris Lattner <sabre at nondot.org> wrote: > > > I don't see how this could be true in general, without either > > knowledge of the malloc implementation, which would be fine, or > > presuming knowledge of the target, which would not be fine. If > > "malloc(sizeof(int))" were changed to

On Sun, 8 Jul 2007, Sandro Magi wrote: > How about if I were to use LLVM's JIT? I suspect plenty of allocations > are performed in the JIT. The JIT does a ton of heap allocation. There is no way to approximate it from the code you give it. -Chris > Sandro > > On 6/20/07, Chris Lattner <sabre at nondot.org> wrote: >> On Wed, 20 Jun 2007, Sandro Magi wrote:

Let me cut it down to the core problem: I'm asking about the feasibility of extending LLVM with constructs to manage separate heaps. Given my current understanding of LLVM, I can see this done in two ways: 1. Add heap management instructions to the core instructions, modify allocation routines to explicitly name heaps or modify the runtime to rebind the allocation routines depending on some

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

Many VMs focus on performance, optimizations, memory consumption, etc. but very few, if any, focus on fault isolation and security. Given memory safety, any VM reduces to capability security, which is sufficient to implement most security policies of interest; however, most such VMs still ignore two main attack vectors from malicious code: DoS attack on memory allocation, and DoS against the CPU.

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

How about if I were to use LLVM's JIT? I suspect plenty of allocations are performed in the JIT. Sandro On 6/20/07, Chris Lattner <sabre at nondot.org> wrote: > On Wed, 20 Jun 2007, Sandro Magi wrote: > > To this end, are there any implicit allocations being done by > > generated LLVM code, other than the system stack? > > heap allocations? Only malloc/free. Note

On 7/10/07, Chris Lattner <sabre at nondot.org> wrote: > On Sun, 8 Jul 2007, Sandro Magi wrote: > > How about if I were to use LLVM's JIT? I suspect plenty of allocations > > are performed in the JIT. > > The JIT does a ton of heap allocation. There is no way to approximate it > from the code you give it. I don't need to approximate it, but I'd like to

On 9/28/07, Chris Lattner <sabre at nondot.org> wrote: > > > Sorry, I meant to ask whether it's still necessary to keep F around, > > ie. to delete generated code. Is there a standard approach to garbage > > collecting code in LLVM? > > Machine code in the JIT buffer or the LLVM IR itself? > Assuming I don't need to keep around the IR version of a