[all-commits] [llvm/llvm-project] fcf341: [coro][CoroSplit] Use `llvm.lifetime.end` to compu...

Alan Zhao via All-commits all-commits at lists.llvm.org
Mon May 6 13:44:15 PDT 2024


  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: fcf341d3ddfe2289ac88aa3c122b25df8732cc8e
      https://github.com/llvm/llvm-project/commit/fcf341d3ddfe2289ac88aa3c122b25df8732cc8e
  Author: Alan Zhao <ayzhao at google.com>
  Date:   2024-05-06 (Mon, 06 May 2024)

  Changed paths:
    M llvm/include/llvm/Analysis/CFG.h
    M llvm/lib/Analysis/CFG.cpp
    M llvm/lib/Transforms/Coroutines/CoroFrame.cpp
    A llvm/test/Transforms/Coroutines/coro-lifetime-end.ll

  Log Message:
  -----------
  [coro][CoroSplit] Use `llvm.lifetime.end` to compute putting objects on the frame vs the stack (#90265)

The current logic for using lifetime intrinsics to determine whether a
coroutine alloca should live on the coroutine frame or stack doesn't
consider `llvm.lifetime.end`. As a result, some allocas are incorrectly
placed on the stack even though their lifetimes may outlive the stack.
For example, SimplifyCFG may generate code that drops the corresponding
`llvm.lifetime.end` of an `llvm.lifetime.start`, and that code is
incorrectly handled by the existing logic.

To fix this, new logic is introduced where if an alloca's address is
escaped, and there is a path from an `llvm.lifetime.start` to a
coroutine suspend point (e.g. `llvm.coro.suspend`) without an
`llvm.lifetime.end`, then we know the object lives beyond the suspension
point and therefore must go on the coroutine frame.

Fixes https://github.com/llvm/llvm-project/issues/86580



To unsubscribe from these emails, change your notification settings at https://github.com/llvm/llvm-project/settings/notifications


More information about the All-commits mailing list