search for: stack_handle

...easier - in general you want to use intrinsics in cases where the presence of the intrinsic will affect the way the code is generated in the calling function. 2) The API that I was envisioning for creating stacks was something fairly simple (maybe too simple): // Create a new stack, where 'stack_handle' is some opaque object, and 'func' // is an LLVM function. stack_handle = llvm.createstack(func, data) // Switch to a different stack (i.e. yield) llvm.switchstack(stack_handle) // deallocate a stack llvm.destroystack(stack_handle) The frontend would be responsible...

...want to use > intrinsics in cases where the presence of the intrinsic will affect the way > the code is generated in the calling function. > 2) The API that I was envisioning for creating stacks was something fairly > simple (maybe too simple): >    // Create a new stack, where 'stack_handle' is some opaque object, and > 'func' >    // is an LLVM function. >    stack_handle = llvm.createstack(func, data) >    // Switch to a different stack (i.e. yield) >    llvm.switchstack(stack_handle) >    // deallocate a stack >    llvm.destroystack(stack_handle) &g...

On Mon, Apr 11, 2011 at 9:07 AM, Sanjoy Das <sanjoy at playingwithpointers.com>wrote: > Hi! > > Thanks for the feedback. For context, my implementation plan is here: > http://pastebin.com/e9JMZNCE > > First, about unwinding: > > In architectures like x86-64, where unwinding based on DWARF info, there > shouldn't be any problems; since the DWARF info will be

Hi! Thanks for the feedback. For context, my implementation plan is here: http://pastebin.com/e9JMZNCE First, about unwinding: In architectures like x86-64, where unwinding based on DWARF info, there shouldn't be any problems; since the DWARF info will be emitted correctly. Otherwise, if the unwinding is done by following BP, it should still be possible to have BP de-reference correctly