[PATCH] Add the llvm.frameallocate and llvm.recoverframeallocation intrinsics

[Reid Kleckner]

In http://reviews.llvm.org/D6493#103064, @sanjoy wrote:

> How is this expected to interact with `nounwind`?  Specifically, can a `nounwind` eventually invoke `recoverframeallocation`?


Yes, all you need is a frame pointer. In the CodeGen/X86/frameallocate.ll test, you can see how this is done with llvm.frameaddress and without throwing any exceptions.

In http://reviews.llvm.org/D6493#103101, @silvas wrote:

> Sorry I'm totally clueless, but can you explain the motivation for this? Perhaps there has been an llvmdev RFC for this feature yet? (I don't see anything in my email, but with the mailing lists lately I'm not sure if I trust my inbox).


The idea came up in the SEH RFC thread here:
http://lists.cs.uiuc.edu/pipermail/llvmdev/2014-November/078771.html
I called it llvm.eh.set_capture_block / llvm.eh.get_capture_block at the time, but it generalizes into basically "allocate something relative to the FP" and "recover that allocation from this specific FP".

The motivation is that various handlers such as cleanups in MSVC C++ and SEH have to be separate functions, and they need to be able to access some local variables in the parent function frame via the frame pointer. Various schemes have been proposed, but so far frameallocate is the least intrusive on the rest of LLVM.

> In the past there have been communication failures without a formal RFC/design discussion on llvmdev to make sure everybody is on the same page (e.g. r209007, although admittedly that was a much more intrusive change than this one), so you probably want to shoot a message there to give everyone a chance to take a look at the design.


I need to recap the original SEH RFC thread, but the design is all out there already.


http://reviews.llvm.org/D6493

EMAIL PREFERENCES
  http://reviews.llvm.org/settings/panel/emailpreferences/