Hi Carlo, rather than declaring individual stack variables int x; int y; int z; and so on, which requires you to pass each one, or a pointer to each one, to your function, declare one stack variable of struct type that holds them all: struct StackObjects { int x; int y; int z; ... }; ... struct StackObjects stack; then pass the address of stack to your function, enabling it to access all of the objects on the callers stack. This way you only need to copy a single pointer. This is what GCC's nested function implementation does for example to enable child functions to access variables on the parent's stack. Ciao, Duncan.
Nella citazione lunedì 22 agosto 2011 11:53:29, Duncan Sands ha scritto:> Hi Carlo, rather than declaring individual stack variables > int x; > int y; > int z; > and so on, which requires you to pass each one, or a pointer to each one, > to your function, declare one stack variable of struct type that holds > them all: > struct StackObjects { > int x; > int y; > int z; > ... > }; > ... > struct StackObjects stack; > then pass the address of stack to your function, enabling it to access all > of the objects on the callers stack. This way you only need to copy a single > pointer. This is what GCC's nested function implementation does for example to > enable child functions to access variables on the parent's stack.Hi Duncan, this is what I'm already doing (see http://stackoverflow.com/questions/7144733/argument-forwarding-in-llvm, the code I posted is in pseudo-C but I'm actually working on LLVM-IR in my pass) but this in curs the boxing-unboxing penalty and I was wondering if there is a way to avoid it. -------------- next part -------------- A non-text attachment was scrubbed... Name: cafxx.vcf Type: text/x-vcard Size: 230 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20110822/72c8d993/attachment.vcf>
Hi Carlo,> Nella citazione lunedì 22 agosto 2011 11:53:29, Duncan Sands ha scritto: >> Hi Carlo, rather than declaring individual stack variables >> int x; >> int y; >> int z; >> and so on, which requires you to pass each one, or a pointer to each one, >> to your function, declare one stack variable of struct type that holds >> them all: >> struct StackObjects { >> int x; >> int y; >> int z; >> ... >> }; >> ... >> struct StackObjects stack; >> then pass the address of stack to your function, enabling it to access all >> of the objects on the callers stack. This way you only need to copy a single >> pointer. This is what GCC's nested function implementation does for example to >> enable child functions to access variables on the parent's stack. > > Hi Duncan, > this is what I'm already doing (see > http://stackoverflow.com/questions/7144733/argument-forwarding-in-llvm, the code > I posted is in pseudo-C but I'm actually working on LLVM-IR in my pass) but this in > curs the boxing-unboxing penalty and I was wondering if there is a way to avoid it.I didn't read your question carefully enough: I thought you were talking about accessing stack variables declared by the parent (in which case there is no cost to using the above technique), but in fact you were talking about accessing the parent's arguments. Probably the best you can do is store a pointer to each argument in a stack struct object (like above), then pass a pointer to that object. The setup cost is then one pointer store per argument, plus one pointer copy (passing the stack object to the callee). The cost of accessing is one pointer dereference per argument. I'm pretty sure this is what GCC does when a nested function wants to access one of its parent's arguments. Ciao, Duncan.