Page MenuHomePhabricator
Feed Advanced Search

Thu, Nov 19

lxfind added a comment to D85812: [coroutine] should disable inline before calling coro split.

Hi @dongAxis1944, @junparser, do you still plan to reland this patch?

Thu, Nov 19, 3:24 PM · Restricted Project

Wed, Nov 18

lxfind added a comment to D86853: [modules] Fix crash in call to `FunctionDecl::setPure()`.

@rsmith, @v.g.vassilev hey I stamped this patch assuming it looks ok. But definitely shout at me if more feedback needs to be addressed. Happy to follow up.

Wed, Nov 18, 2:14 PM · Restricted Project
lxfind committed rGc6c8d4a13ebd: [modules] Fix crash in call to `FunctionDecl::setPure()` (authored by andrewjcg).
[modules] Fix crash in call to `FunctionDecl::setPure()`
Wed, Nov 18, 11:56 AM
lxfind closed D86853: [modules] Fix crash in call to `FunctionDecl::setPure()`.
Wed, Nov 18, 11:56 AM · Restricted Project
lxfind accepted D86853: [modules] Fix crash in call to `FunctionDecl::setPure()`.
Wed, Nov 18, 11:43 AM · Restricted Project

Mon, Nov 16

lxfind committed rG985c524001d4: [Coroutine] Allocas used by StoreInst does not always escape (authored by lxfind).
[Coroutine] Allocas used by StoreInst does not always escape
Mon, Nov 16, 9:15 AM
lxfind closed D91305: [Coroutine] Allocas used by StoreInst does not always escape.
Mon, Nov 16, 9:15 AM · Restricted Project
lxfind added a comment to D87798: [NewPM][CGSCC] Handle newly added functions in updateCGAndAnalysisManagerForPass.

Yes I'm aware of the issue and https://reviews.llvm.org/D88714 is an attempt to fix that. I was going to ask exactly what sorts of transformations coroutines does. I'll make a post in llvm-dev.

Mon, Nov 16, 9:02 AM · Restricted Project

Sat, Nov 14

lxfind added a comment to D91305: [Coroutine] Allocas used by StoreInst does not always escape.

Thanks for the patch!

Sat, Nov 14, 8:57 PM · Restricted Project
lxfind added a comment to D87798: [NewPM][CGSCC] Handle newly added functions in updateCGAndAnalysisManagerForPass.

Yes I'm aware of the issue and https://reviews.llvm.org/D88714 is an attempt to fix that. I was going to ask exactly what sorts of transformations coroutines does. I'll make a post in llvm-dev.

Sat, Nov 14, 12:58 PM · Restricted Project
lxfind added a comment to D87798: [NewPM][CGSCC] Handle newly added functions in updateCGAndAnalysisManagerForPass.

@aeubanks, I was wondering if you are familiar with this but it seems that the SCC update after CoroSplit couldn't handle the case when there is recursion in the original coroutine, that is, the newly generated functions by CoroSplit will contain cycles (foo calling foo.resume which then calls foo). Do you have suggestions/thoughts on how to fix it?
For example, test like this will fail assertions:

; RUN: opt < %s --enable-new-pm --enable-coroutines -O3 -S
; Function Attrs: argmemonly nounwind readonly
declare token @llvm.coro.id(i32, i8* readnone, i8* nocapture readonly, i8*) #0
Sat, Nov 14, 8:59 AM · Restricted Project

Fri, Nov 13

lxfind added a comment to D91305: [Coroutine] Allocas used by StoreInst does not always escape.

Do we really need handle this in non-optimized mode? @bruno I'm afraid that this patch may affect the debugging quality fixed in D90772, @lxfind, have you ever checked this?

Fri, Nov 13, 9:44 PM · Restricted Project
lxfind added inline comments to D91098: [coro] Async coroutines: Allow more than 3 arguments in the dispatch function.
Fri, Nov 13, 1:26 PM · Restricted Project

Thu, Nov 12

lxfind added a comment to D91305: [Coroutine] Allocas used by StoreInst does not always escape.

I'm not sure whether we should fix this case by case. Maybe we should use memoryssa to handle this.

Thu, Nov 12, 8:55 PM · Restricted Project

Wed, Nov 11

lxfind added a reverting change for rG8bc7b9278e55: [Coroutine] Allocas used by StoreInst does not always escape: rG94a45a809872: Revert "[Coroutine] Allocas used by StoreInst does not always escape".
Wed, Nov 11, 9:10 PM
lxfind committed rG94a45a809872: Revert "[Coroutine] Allocas used by StoreInst does not always escape" (authored by lxfind).
Revert "[Coroutine] Allocas used by StoreInst does not always escape"
Wed, Nov 11, 9:10 PM
lxfind added a reverting change for D91305: [Coroutine] Allocas used by StoreInst does not always escape: rG94a45a809872: Revert "[Coroutine] Allocas used by StoreInst does not always escape".
Wed, Nov 11, 9:10 PM · Restricted Project
lxfind reopened D91305: [Coroutine] Allocas used by StoreInst does not always escape.

Landed by accident. Reverted and reopening for review.

Wed, Nov 11, 9:10 PM · Restricted Project
lxfind committed rG8bc7b9278e55: [Coroutine] Allocas used by StoreInst does not always escape (authored by lxfind).
[Coroutine] Allocas used by StoreInst does not always escape
Wed, Nov 11, 8:54 PM
lxfind closed D91305: [Coroutine] Allocas used by StoreInst does not always escape.
Wed, Nov 11, 8:54 PM · Restricted Project
lxfind accepted D91243: [NFC][Coroutines] Remove unused `IsImplicit` argument in maybeTailCall.

Thank you!

Wed, Nov 11, 8:24 PM · Restricted Project
lxfind added a comment to D90752: [OpenMP][OMPT] Update the omp-tools header file to reflect 5.1 changes.

Are all uses of on_ompt_callback_master expected to be replaced?
I see this is still using it:
https://github.com/llvm/llvm-project/blob/master/openmp/tools/multiplex/tests/custom_data_storage/first-tool.h#L126

Wed, Nov 11, 4:40 PM · Restricted Project
lxfind added reviewers for D91305: [Coroutine] Allocas used by StoreInst does not always escape: ChuanqiXu, junparser, bruno, wenlei.
Wed, Nov 11, 3:51 PM · Restricted Project
lxfind requested review of D91305: [Coroutine] Allocas used by StoreInst does not always escape.
Wed, Nov 11, 3:50 PM · Restricted Project
lxfind added a comment to D91243: [NFC][Coroutines] Remove unused `IsImplicit` argument in maybeTailCall.

Good catch. Thanks for the fix! The IsImplicit argument for buildCoawaitCalls function can also be removed now.

Wed, Nov 11, 10:11 AM · Restricted Project

Tue, Nov 10

lxfind committed rGb8a8ef32762b: [SafeStack] Make sure SafeStack does not break musttail call contract (authored by lxfind).
[SafeStack] Make sure SafeStack does not break musttail call contract
Tue, Nov 10, 8:46 PM
lxfind closed D90702: [SafeStack] Make sure SafeStack does not break musttail call contract.
Tue, Nov 10, 8:46 PM · Restricted Project
lxfind added inline comments to D91018: [ELF] Make InputSection smaller.
Tue, Nov 10, 8:25 PM · Restricted Project
lxfind added inline comments to D91018: [ELF] Make InputSection smaller.
Tue, Nov 10, 5:21 PM · Restricted Project
lxfind added inline comments to D88059: [Coroutine] Split PHI Nodes in `cleanuppad` blocks in a way that obeys EH pad rules.
Tue, Nov 10, 2:22 PM · Restricted Project
lxfind committed rG19f077092343: [Coroutine][Sema] Cleanup temporaries as early as possible (authored by lxfind).
[Coroutine][Sema] Cleanup temporaries as early as possible
Tue, Nov 10, 1:28 PM
lxfind closed D90990: [Coroutine][Sema] Cleanup temporaries as early as possible.
Tue, Nov 10, 1:27 PM · Restricted Project
lxfind added a comment to D90702: [SafeStack] Make sure SafeStack does not break musttail call contract.

ping :)

Tue, Nov 10, 10:01 AM · Restricted Project
lxfind planned changes to D89711: [Coroutine] Prevent value reusing across coroutine suspensions in EarlyCSE and GVN.
Tue, Nov 10, 10:00 AM · Restricted Project
lxfind updated the diff for D90990: [Coroutine][Sema] Cleanup temporaries as early as possible.

Add AST test

Tue, Nov 10, 9:23 AM · Restricted Project
lxfind added inline comments to D90990: [Coroutine][Sema] Cleanup temporaries as early as possible.
Tue, Nov 10, 8:31 AM · Restricted Project
lxfind added inline comments to D90990: [Coroutine][Sema] Cleanup temporaries as early as possible.
Tue, Nov 10, 8:21 AM · Restricted Project

Mon, Nov 9

lxfind added a comment to D90612: Start of an llvm.coro.async implementation.

Curious, is the plan to eventually replace .recon lowering with .async lowering? If so, would you mind explain in a bit more detail what's the advantage of .async over .retcon lowering and what motivates this new lowering? Thanks!

Mon, Nov 9, 5:35 PM · Restricted Project
lxfind accepted D90772: [Coroutines] Add missing llvm.dbg.declare's to cover more allocas.

LGTM. Thanks!

Mon, Nov 9, 5:25 PM · Restricted Project
lxfind committed rGc2cb093d9b96: [Coroutine] Move all used local allocas to the .resume function (authored by lxfind).
[Coroutine] Move all used local allocas to the .resume function
Mon, Nov 9, 5:25 PM
lxfind closed D90977: [Coroutine] Move all used local allocas to the .resume function.
Mon, Nov 9, 5:25 PM · Restricted Project
lxfind added a comment to D90977: [Coroutine] Move all used local allocas to the .resume function.

I can confirm that this fixes the crash we've been seeing - thank you!

Mon, Nov 9, 1:07 PM · Restricted Project
lxfind added a comment to D90772: [Coroutines] Add missing llvm.dbg.declare's to cover more allocas.

Could you add a test (or update existing tests) to demonstrate that the issue is fixed?

The testcase was updated as part of the last diff update, anything specific you are looking for?

Mon, Nov 9, 11:46 AM · Restricted Project

Fri, Nov 6

lxfind added a comment to D90772: [Coroutines] Add missing llvm.dbg.declare's to cover more allocas.

Could you add a test (or update existing tests) to demonstrate that the issue is fixed?

Fri, Nov 6, 6:41 PM · Restricted Project
lxfind updated the summary of D90990: [Coroutine][Sema] Cleanup temporaries as early as possible.
Fri, Nov 6, 4:32 PM · Restricted Project
lxfind updated the summary of D90990: [Coroutine][Sema] Cleanup temporaries as early as possible.
Fri, Nov 6, 4:31 PM · Restricted Project
lxfind updated the summary of D90990: [Coroutine][Sema] Cleanup temporaries as early as possible.
Fri, Nov 6, 4:31 PM · Restricted Project
lxfind updated the summary of D90990: [Coroutine][Sema] Cleanup temporaries as early as possible.
Fri, Nov 6, 4:31 PM · Restricted Project
lxfind updated the summary of D90990: [Coroutine][Sema] Cleanup temporaries as early as possible.
Fri, Nov 6, 4:31 PM · Restricted Project
lxfind requested review of D90990: [Coroutine][Sema] Cleanup temporaries as early as possible.
Fri, Nov 6, 4:29 PM · Restricted Project
lxfind updated the diff for D90702: [SafeStack] Make sure SafeStack does not break musttail call contract.

auto generate test

Fri, Nov 6, 3:39 PM · Restricted Project
lxfind updated the diff for D90977: [Coroutine] Move all used local allocas to the .resume function.

rebase

Fri, Nov 6, 3:04 PM · Restricted Project
lxfind added reviewers for D90977: [Coroutine] Move all used local allocas to the .resume function: wenlei, junparser, ChuanqiXu, ben-clayton.
Fri, Nov 6, 3:03 PM · Restricted Project
lxfind updated the diff for D90977: [Coroutine] Move all used local allocas to the .resume function.

update description

Fri, Nov 6, 3:03 PM · Restricted Project
lxfind updated the diff for D90977: [Coroutine] Move all used local allocas to the .resume function.

update description

Fri, Nov 6, 3:02 PM · Restricted Project
lxfind requested review of D90977: [Coroutine] Move all used local allocas to the .resume function.
Fri, Nov 6, 2:56 PM · Restricted Project
lxfind added a comment to D89768: [Coroutine] Properly determine whether an alloca should live on the frame.

Hello,

A git bisect has identified this change as the likely candidate for a new set of asserts / crashes in SwiftShader when attempting to use the coroutine passes. This is having knock-on issues with internal Google projects.

When passing this IR to ./bin/opt crash.ir -coro-early -coro-split -coro-elide -S with this change, we now get this crash.
Running the same command on the parent change does not crash, and behaves as expected.

I'd like to file a bug, but LLVM's Bugzilla is not letting me sign in, possibly due to spam restrictions. :-/

I'll do some investigation myself tomorrow, but any assistance here would be gratefully appreciated.

Many thanks,
Ben

Fri, Nov 6, 11:43 AM · Restricted Project

Thu, Nov 5

lxfind added a comment to D89768: [Coroutine] Properly determine whether an alloca should live on the frame.

Hello,

A git bisect has identified this change as the likely candidate for a new set of asserts / crashes in SwiftShader when attempting to use the coroutine passes. This is having knock-on issues with internal Google projects.

When passing this IR to ./bin/opt crash.ir -coro-early -coro-split -coro-elide -S with this change, we now get this crash.
Running the same command on the parent change does not crash, and behaves as expected.

I'd like to file a bug, but LLVM's Bugzilla is not letting me sign in, possibly due to spam restrictions. :-/

I'll do some investigation myself tomorrow, but any assistance here would be gratefully appreciated.

Many thanks,
Ben

Thu, Nov 5, 3:08 PM · Restricted Project

Wed, Nov 4

lxfind added a comment to D90772: [Coroutines] Add missing llvm.dbg.declare's to cover more allocas.

Thank you for working on this!

Wed, Nov 4, 11:38 AM · Restricted Project

Tue, Nov 3

lxfind committed rG7f34aca083b5: [musttail] Unify musttail call preceding return checking (authored by lxfind).
[musttail] Unify musttail call preceding return checking
Tue, Nov 3, 11:40 AM
lxfind closed D90693: [musttail] Unify musttail call preceding return checking.
Tue, Nov 3, 11:40 AM · Restricted Project
lxfind requested review of D90702: [SafeStack] Make sure SafeStack does not break musttail call contract.
Tue, Nov 3, 11:37 AM · Restricted Project
lxfind requested review of D90693: [musttail] Unify musttail call preceding return checking.
Tue, Nov 3, 10:05 AM · Restricted Project

Fri, Oct 30

lxfind added a comment to D89768: [Coroutine] Properly determine whether an alloca should live on the frame.
Fri, Oct 30, 9:02 AM · Restricted Project

Thu, Oct 29

lxfind committed rG9f5a2beadce4: [Coroutine] Properly determine whether an alloca should live on the frame (authored by lxfind).
[Coroutine] Properly determine whether an alloca should live on the frame
Thu, Oct 29, 11:56 PM
lxfind closed D89768: [Coroutine] Properly determine whether an alloca should live on the frame.
Thu, Oct 29, 11:56 PM · Restricted Project

Oct 28 2020

lxfind added inline comments to D89768: [Coroutine] Properly determine whether an alloca should live on the frame.
Oct 28 2020, 9:13 AM · Restricted Project

Oct 27 2020

lxfind added inline comments to D89768: [Coroutine] Properly determine whether an alloca should live on the frame.
Oct 27 2020, 11:24 PM · Restricted Project
lxfind added inline comments to D89768: [Coroutine] Properly determine whether an alloca should live on the frame.
Oct 27 2020, 11:13 PM · Restricted Project
lxfind added inline comments to D89768: [Coroutine] Properly determine whether an alloca should live on the frame.
Oct 27 2020, 11:10 PM · Restricted Project
lxfind added inline comments to D89768: [Coroutine] Properly determine whether an alloca should live on the frame.
Oct 27 2020, 10:56 PM · Restricted Project
lxfind added inline comments to D89768: [Coroutine] Properly determine whether an alloca should live on the frame.
Oct 27 2020, 10:43 PM · Restricted Project
lxfind added inline comments to D89768: [Coroutine] Properly determine whether an alloca should live on the frame.
Oct 27 2020, 8:57 AM · Restricted Project

Oct 26 2020

lxfind added a comment to D89768: [Coroutine] Properly determine whether an alloca should live on the frame.

Thanks for the patch! I think I generally agree with this patch.
One thing is that the aliases seems to be over-analyzed. Can we just leave aliases on frame? Cause I have no idea about this effect on real workloads.

Oct 26 2020, 10:43 AM · Restricted Project
lxfind added inline comments to D89768: [Coroutine] Properly determine whether an alloca should live on the frame.
Oct 26 2020, 10:15 AM · Restricted Project

Oct 22 2020

lxfind added a comment to D89768: [Coroutine] Properly determine whether an alloca should live on the frame.

Great! To my understanding, if there are lifetime informations, the behavior of this patch is same with the behavior of previous implementation. Is my understanding right?

Oct 22 2020, 7:38 PM · Restricted Project

Oct 21 2020

lxfind added a comment to D89768: [Coroutine] Properly determine whether an alloca should live on the frame.

Okay. Well, it does seem to me that we need to be considering lifetimes. If we can also optimize when we don't have lifetime information and the variable doesn't escape, that's great, but we often have pretty good lifetime information that we can use. And in optimized builds we'll usually have already eliminated allocas that don't escape, so the remaining allocas are very likely to have all escaped.

Oct 21 2020, 4:16 PM · Restricted Project
lxfind added a comment to D89768: [Coroutine] Properly determine whether an alloca should live on the frame.

There's an existing StackLifetime analysis that does some of this work and also considers the lifetime intrinsics; can we take advantage of that?

Oct 21 2020, 12:44 PM · Restricted Project

Oct 20 2020

lxfind added a comment to D89711: [Coroutine] Prevent value reusing across coroutine suspensions in EarlyCSE and GVN.

but that would also mean we would never be able to optimize out redundant pthread_self() calls

We can probably mess with alias analysis so it understands that pthread_self doesn't alias operations other than calls to a coroutine suspend; that should be enough to recover the relevant optimizations. Not sure if we want to add some sort of IR attribute, or just special-case that specific library call using TargetLibraryInfo.

And yes thread local variables are another set of problems. I don't have a solution yet on how to handle them.

We probably need an intrinsic that computes the runtime address of a thread-local variable, so we compute the address at some specific point in the function.

Oct 20 2020, 12:29 PM · Restricted Project
lxfind updated the diff for D89768: [Coroutine] Properly determine whether an alloca should live on the frame.

clang-tidy

Oct 20 2020, 11:40 AM · Restricted Project

Oct 19 2020

lxfind requested review of D89768: [Coroutine] Properly determine whether an alloca should live on the frame.
Oct 19 2020, 11:39 PM · Restricted Project
lxfind added a comment to D89711: [Coroutine] Prevent value reusing across coroutine suspensions in EarlyCSE and GVN.

but that would also mean we would never be able to optimize out redundant pthread_self() calls

We can probably mess with alias analysis so it understands that pthread_self doesn't alias operations other than calls to a coroutine suspend; that should be enough to recover the relevant optimizations. Not sure if we want to add some sort of IR attribute, or just special-case that specific library call using TargetLibraryInfo.

And yes thread local variables are another set of problems. I don't have a solution yet on how to handle them.

We probably need an intrinsic that computes the runtime address of a thread-local variable, so we compute the address at some specific point in the function.

Oct 19 2020, 4:49 PM · Restricted Project
lxfind added a comment to D89711: [Coroutine] Prevent value reusing across coroutine suspensions in EarlyCSE and GVN.

For the first point, if the IR definition isn't consistent, I'd prefer to actually fix that, instead of work around it. There are a lot of places that assume alias analysis is accurate.

For example, the glibc library pthread_self is defined with attribute((const)) (which would have readnone attribute in LLVM IR) even though it in fact reads global memory.

Can we fix up the attributes on pthread_self in clang? Or are we more generally concerned with people marking their functions const?

On a related note, we probably need to change the representation of references to thread-local variables.


For the second point, it isn't obvious to me that disabling CSE is universally profitable. We can actually end up reducing the number of values live across the suspend point in some cases. And it seems simpler to teach coroutine lowering to rematerialize instructions when it's profitable.

Oct 19 2020, 11:27 AM · Restricted Project
lxfind requested review of D89711: [Coroutine] Prevent value reusing across coroutine suspensions in EarlyCSE and GVN.
Oct 19 2020, 10:02 AM · Restricted Project

Oct 13 2020

lxfind added inline comments to D89191: [ASAN] Make sure we are only processing lifetime markers with offset 0 to alloca.
Oct 13 2020, 11:18 PM · Restricted Project
lxfind committed rG0ccf9263cceb: [ASAN] Make sure we are only processing lifetime markers with offset 0 to alloca (authored by lxfind).
[ASAN] Make sure we are only processing lifetime markers with offset 0 to alloca
Oct 13 2020, 10:22 AM
lxfind closed D89191: [ASAN] Make sure we are only processing lifetime markers with offset 0 to alloca.
Oct 13 2020, 10:22 AM · Restricted Project
lxfind added inline comments to D89191: [ASAN] Make sure we are only processing lifetime markers with offset 0 to alloca.
Oct 13 2020, 10:20 AM · Restricted Project

Oct 12 2020

lxfind committed rGd80ecdf27faf: [Coroutine] Rename coro-semmetric-transfer.cpp and possibly fix test failure (authored by lxfind).
[Coroutine] Rename coro-semmetric-transfer.cpp and possibly fix test failure
Oct 12 2020, 3:29 PM
lxfind closed D89269: [Coroutine] Rename coro-semmetric-transfer.cpp and fix test failure.
Oct 12 2020, 3:29 PM · Restricted Project
lxfind retitled D89269: [Coroutine] Rename coro-semmetric-transfer.cpp and fix test failure from [Coroutine] Rename coro-semmetric-transfer.cpp and possibly fix test failure to [Coroutine] Rename coro-semmetric-transfer.cpp and fix test failure.
Oct 12 2020, 2:52 PM · Restricted Project
lxfind added a comment to D89066: [Coroutine][Sema] Only tighten the suspend call temp lifetime for final awaiter.

Test failures are being fixed in https://reviews.llvm.org/D89269.

Oct 12 2020, 2:21 PM · Restricted Project
lxfind requested review of D89269: [Coroutine] Rename coro-semmetric-transfer.cpp and fix test failure.
Oct 12 2020, 2:20 PM · Restricted Project
lxfind added a comment to D89066: [Coroutine][Sema] Only tighten the suspend call temp lifetime for final awaiter.

There seems to be build failures in the buildbot, but I don't understand why it's happening.. (unable to repro locally and the patterns seem correct)
http://lab.llvm.org:8011/#/builders/12/builds/92/steps/7/logs/FAIL__Clang__coro-semmetric-transfer_cpp

Oct 12 2020, 12:45 PM · Restricted Project
lxfind committed rGdce8f2bb25ea: [Coroutine][Sema] Only tighten the suspend call temp lifetime for final awaiter (authored by lxfind).
[Coroutine][Sema] Only tighten the suspend call temp lifetime for final awaiter
Oct 12 2020, 12:01 PM
lxfind closed D89066: [Coroutine][Sema] Only tighten the suspend call temp lifetime for final awaiter.
Oct 12 2020, 12:00 PM · Restricted Project
lxfind updated the diff for D89066: [Coroutine][Sema] Only tighten the suspend call temp lifetime for final awaiter.

Add more comments and TODO

Oct 12 2020, 11:59 AM · Restricted Project
lxfind added inline comments to D89191: [ASAN] Make sure we are only processing lifetime markers with offset 0 to alloca.
Oct 12 2020, 9:51 AM · Restricted Project
lxfind added a comment to D89066: [Coroutine][Sema] Only tighten the suspend call temp lifetime for final awaiter.

why we should not do this with normal await call?

To be honest, I don't know yet. My understanding of how expression cleanup and temp lifetime management is insufficient at the moment.
But first of all, without adding any cleanup expression here, I saw ASAN failures due to heap-use-after-free, because sometimes the frame have already been destroyed after the await_suspend call, and yet we are still writing into the frame due to unnecessarily cross-suspend lifetime. However, if I apply the cleanup to all await_suepend calls, it also causes ASAN failures as it's cleaning up data that's still alive.
So this patch is more of a temporary walkaround to stop bleeding without causing any trouble.
I plan to get back to this latter after I am done with the spilling/alloca issues.

I'm not familiar with ASAN instrumentation. Do you have any testcases to explain this?

Oct 12 2020, 9:44 AM · Restricted Project

Oct 11 2020

lxfind added a comment to D89066: [Coroutine][Sema] Only tighten the suspend call temp lifetime for final awaiter.

why we should not do this with normal await call?

Oct 11 2020, 10:23 PM · Restricted Project