similar to: [LLVMdev] Accounting for stack space

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

On Tue, 10 Jul 2007, Sandro Magi wrote: >> used. Your choices are to either override malloc/free for both the JIT >> and the program or for neither of them. > > I want to 'intercept' ALL allocations actually, including the stack if > possible, so the above suits me just fine. Ok, just provide your own malloc/free. :) -Chris -- http://nondot.org/sabre/

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

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

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:

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.

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 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 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 Tue, 10 Jul 2007, Sandro Magi wrote: > 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.

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 Jul 10, 2007, at 15:39, Chris Lattner wrote: > On Tue, 10 Jul 2007, Sandro Magi wrote: > >>> used. Your choices are to either override malloc/free for both >>> the JIT and the program or for neither of them. >> >> I want to 'intercept' ALL allocations actually, including the >> stack if possible, so the above suits me just fine. > >

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, 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 7/10/07, Chris Lattner <sabre at nondot.org> wrote: > > For instance, is it possible to entirely replace the malloc/free > > called by the LLVM libraries with my own implementation? This would > > achieve my goals, as I'm not against heap allocations, I just need to > > be able to measure them. > > Not really. The JIT allocates from the same heap as the

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

Where does the storage for large bit width integers come from? Are very large numbers heap allocated? Sandro

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 Sep 28, 2007, at 11:00 AM, Sandro Magi wrote: > 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