[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