You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Right now, LLVM memory objects are deeply coupled to control flow via the StackFrame and BranchFrame constructors. This is problematic as we consider taking concurrency more seriously in the future.
Issue #890 is already basically about the coupling induced by BranchFrame. However, we should also deal with the implications of StackFrame. Rather than a linear stack of frames, the memory should instead have a more general notion of a "stack region" in which stack allocations can live. Individual threads will keep track of when and in what order to deallocate the regions representing their stack frames, the memory model just needs to know which allocations live within which regions and doesn't need to impose a well-bracketed discipline on them.
The text was updated successfully, but these errors were encountered:
Right now, LLVM memory objects are deeply coupled to control flow via the
StackFrame
andBranchFrame
constructors. This is problematic as we consider taking concurrency more seriously in the future.Issue #890 is already basically about the coupling induced by
BranchFrame
. However, we should also deal with the implications ofStackFrame
. Rather than a linear stack of frames, the memory should instead have a more general notion of a "stack region" in which stack allocations can live. Individual threads will keep track of when and in what order to deallocate the regions representing their stack frames, the memory model just needs to know which allocations live within which regions and doesn't need to impose a well-bracketed discipline on them.The text was updated successfully, but these errors were encountered: