similar to: [LLVMdev] Do explicitly managed stack frames free the stack register?

> [1] http://nondot.org/sabre/LLVMNotes/ExplicitlyManagedStackFrames.txt Interesting. Something like this is more then sufficient for implementing by value structure passing at the llvm level :-) Cheers, -- Rafael Avila de Espindola Google Ireland Ltd. Gordon House Barrow Street Dublin 4 Ireland Registered in Dublin, Ireland Registration Number: 368047

William Morgan wrote: > Hi all, > > At the bottom of chapter 8 of the tutorial, on the topic of closures, > mentions that there are "often better ways to implement these features > than explicit stack frames". Does anyone know what techniques this > cryptic statement might be referring to? > > Thanks! > I would say it means to have a "stackless"

Hi all, At the bottom of chapter 8 of the tutorial, on the topic of closures, mentions that there are "often better ways to implement these features than explicit stack frames". Does anyone know what techniques this cryptic statement might be referring to? Thanks! -- William <wmorgan-llvm at masanjin.net>

Hi, going through the tutorial (http://llvm.org/docs/tutorial/LangImpl8.html) it linked to a post from 2004 (http://nondot.org/sabre/LLVMNotes/ExplicitlyManagedStackFrames.txt) stating that LLVM does not allow explicit stack management. It also mentioned that this was a deficiency in LLVM, leading me to think that there is a possibility that things have changed since them. I'm not just

On Thu, Jul 16, 2009 at 9:29 PM, Joshua Moore-Oliva<llvm-dev at chatgris.com> wrote: > To the list of modifications I need to be able to perform, add > > the ability to specify the ordering of local variables in the stack If you need specific locations for everything you're allocating on the stack, you should probably just use a continuation-passing style like the one mentioned

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

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,

I was wondering what the current state of this (explicitly managed stack frames) is. Is it being worked on? If not, how hard do you think it would be for me to add it? I am more than willing to work on it, but don't have any experience with LLVM, so it might take a while. The reason I ask is because I am starting work on a project to make a language similar to ML with which to experiment,

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 Mar 31, 2009, at 11:46 AM, Alireza.Moshtaghi at microchip.com wrote: > Any thoughts on this? > I would like to get it right before jumping into the nuts and bolts > of it…. Did you see this Ali? http://nondot.org/sabre/LLVMNotes/ExtendedIntegerResults.txt -Chris -------------- next part -------------- An HTML attachment was scrubbed... URL:

> Did you see this Ali? > http://nondot.org/sabre/LLVMNotes/ExtendedIntegerResults.txt Would you mind adding it to SVN? Would make it easier to comment on. In particular, it would be nice to add examples for X86 (caller extends. High bits undefined in the callee) and PPC (callee extends). And I still don't understand why in short y(); int z() { return ((int)y() << 16) >>

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:

Any thoughts on this? I would like to get it right before jumping into the nuts and bolts of it.... Thanks ________________________________ From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Alireza.Moshtaghi at microchip.com Sent: Thursday, March 12, 2009 10:39 AM To: llvmdev at cs.uiuc.edu Subject: RE: [LLVMdev] promotion of return value.

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

To the list of modifications I need to be able to perform, add the ability to specify the ordering of local variables in the stack the ability to have one thread access the contents of another thread's stack. There may be more I am forgetting, so simply put I need to be able to have complete control over the stack. It's layout, its contents etc.

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

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