search for: returnaddr

Hi! I noticed in the LegalizeDAG.cpp (SelectionDAGLegalize::LegalizeOp): case ISD::INIT_TRAMPOLINE: case ISD::FRAMEADDR: case ISD::RETURNADDR: // These operations lie about being legal: when they claim to be legal, // they should actually be custom-lowered. Action = TLI.getOperationAction(Node->getOpcode(), Node->getValueType(0)); if (Action == TargetLowering::Legal) Action = TargetLowering::Custom; break;...

...any efficient solution short of making the backend aware of object pointer types. i.e. Machine operands need to carry these types. For stack walking, what do you need in addition to DWARF unwind? Or is generating correct unwind tables the problem? I'm not sure what stack intrinsics you mean... returnaddress and frameaddress? They don't always work if you provide the necessary target options? It almost sounds like you want more control than libunwind provides? Or do you want more efficiency? > Light-weight coroutines would be a "nice to have", as would better concurrency primitives...

...tially means an API that can reliably iterate through all of the stack frames, starting from the current function, and calculate the correct return address for each stack frame. I'm envisioning something like this: frame = llvm.currentframe(); while frame != NULL { retaddr = llvm.returnaddr(frame); // do stack tracing using frame and retaddr to identify stack roots. frame = llvm.nextframe(frame); } This is essentially what I do now with the EBP register - but it would be better if it were encapsulated behind an API, so that frontends wouldn't have to know about sp...

On Apr 10, 2011, at 2:45 PM, Talin wrote: > I wonder - would something like this allow for multiple stacks for a single thread? I'm thinking of something like continuations / fibers / green threads, which would be very handy. I haven't looked at the proposal, but yes, this would be very useful functionality for LLVM to provide. -Chris > > On Wed, Mar 23, 2011 at 3:07 AM,

So I've been using LLVM for about 4 years now, and I've posted a lot on this list about specific issues. What I would like to do is step back for a moment and give my "big picture" assessment of LLVM overall, particularly with respect to developing a "managed" language like Java / C# or my own language, Tart. Obviously, I feel that LLVM is the best choice out there,