[PATCH] D157499: [IR] Add dead_on_unwind attribute

Nikita Popov via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Tue Aug 15 11:36:03 PDT 2023


nikic added a comment.

In D157499#4589106 <https://reviews.llvm.org/D157499#4589106>, @efriedma wrote:

> I'm mostly concerned that depending on the size of the allocation leads to weird results if, for example, the caller decides to merge two allocas.  For example, you have a function `f(ptr dead_on_unwind, ptr)`, and the caller passes each argument a pointer to an `alloca i32`.  If the caller merge those two allocas into `{i32, i32}`, you'd expect the semantics to stay consistent... but if the whole allocation is "dead", then merging affects stores through the second pointer.  So using the "allocation" as the boundary isn't really well-defined.

Okay, I can see the concern. In that case, I would suggest the following wording:

> At a high level, this attribute indicates that the pointer argument is dead if the call unwinds, in the sense that the caller will not depend on the contents of the memory. Stores that would only be visible on the unwind path can be elided.
>
> More precisely, the behavior is as-if the memory within the `dereferenceable` region of the pointer argument (if any), as well as any memory written through the pointer during the execution of the function, is overwritten with a `poison` value on unwind. The caller is allowed to access the affected memory, but all loads that are not preceded by a store will return poison.
>
> This attribute cannot be applied to return values.

This should allow all the motivating optimizations without additional checks, while still allowing things like alloca merging or alloca reuse.

Does that sound reasonable?


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D157499/new/

https://reviews.llvm.org/D157499



More information about the llvm-commits mailing list