Design and Usage of the InAlloca Attribute

For now, it is recommended that frontends and optimizers avoid producingthis construct, primarily because it forces the use of a base pointer.This feature may grow in the future to allow general mid-leveloptimization, but for now, it should be regarded as less efficient thanpassing by value with a copy.

The example below is the intended LLVM IR lowering for some C++ codethat passes two default-constructed objects to g in the32-bit Microsoft C++ ABI.

To avoid stack leaks, the frontend saves the current stack pointer witha call to llvm.stacksave. Then, it allocates theargument stack space with alloca and calls the default constructor. Thedefault constructor could throw an exception, so the frontend has tocreate a landing pad. The frontend has to destroy the alreadyconstructed argument b before restoring the stack pointer. If theconstructor does not unwind, is called. In the Microsoft C++ ABI,g will destroy its arguments, and then the stack is restored inf.

The rule against allocas between argument allocations and the call siteavoids this problem, but it creates a cleanup problem. Cleanup andlifetime is handled explicitly with stack save and restore calls. Inthe future, we may want to introduce a new construct such as or afree to make it clear that this stack adjusting cleanup is lesspowerful than a full stack save and restore.

We also want to be able to support copy elision into these argumentslots. This means we have to support multiple live argumentallocations.

Consider the evaluation of:

Another wrinkle is the existence of callee-cleanup conventions. OnWindows, all methods and many other functions adjust the stack to clearthe memory used to pass their arguments. In some sense, this means thatthe allocas are automatically cleared by the call. However, LLVMinstead models this as a write of undef to all of the inalloca valuespassed to the call instead of a stack adjustment. Frontends shouldstill restore the stack pointer to avoid a stack leak.

There is also the possibility of an exception. If argument evaluationor copy construction throws an exception, the landing pad must docleanup, which includes adjusting the stack pointer to avoid a stackleak. This means the cleanup of the stack memory cannot be tied to thecall itself. There needs to be a separate IR-level instruction that canperform independent cleanup of arguments.

Eventually, it should be possible to generate efficient code for thisconstruct. In particular, using inalloca should not require a basepointer. If the backend can prove that all points in the CFG only haveone possible stack level, then it can address the stack directly fromthe stack pointer. While this is not yet implemented, the plan is thatthe inalloca attribute should not change much, but the frontend IRgeneration recommendations may change.