Page MenuHomePhabricator

lxfind (Xun Li)
User

Projects

User does not belong to any projects.

User Details

User Since
May 3 2020, 4:37 PM (25 w, 17 h)

Recent Activity

Today

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

Thu, Oct 22

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?

Thu, Oct 22, 7:38 PM · Restricted Project

Wed, Oct 21

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.

Wed, Oct 21, 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?

Wed, Oct 21, 12:44 PM · Restricted Project

Tue, Oct 20

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.

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

clang-tidy

Tue, Oct 20, 11:40 AM · Restricted Project

Mon, Oct 19

lxfind requested review of D89768: [Coroutine] Properly determine whether an alloca should live on the frame.
Mon, Oct 19, 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.

Mon, Oct 19, 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.

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

Tue, Oct 13

lxfind added inline comments to D89191: [ASAN] Make sure we are only processing lifetime markers with offset 0 to alloca.
Tue, Oct 13, 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
Tue, Oct 13, 10:22 AM
lxfind closed D89191: [ASAN] Make sure we are only processing lifetime markers with offset 0 to alloca.
Tue, Oct 13, 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.
Tue, Oct 13, 10:20 AM · Restricted Project

Mon, Oct 12

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
Mon, Oct 12, 3:29 PM
lxfind closed D89269: [Coroutine] Rename coro-semmetric-transfer.cpp and fix test failure.
Mon, Oct 12, 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.
Mon, Oct 12, 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.

Mon, Oct 12, 2:21 PM · Restricted Project
lxfind requested review of D89269: [Coroutine] Rename coro-semmetric-transfer.cpp and fix test failure.
Mon, Oct 12, 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 reasonable)
http://lab.llvm.org:8011/#/builders/12/builds/92/steps/7/logs/FAIL__Clang__coro-semmetric-transfer_cpp

Mon, Oct 12, 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
Mon, Oct 12, 12:01 PM
lxfind closed D89066: [Coroutine][Sema] Only tighten the suspend call temp lifetime for final awaiter.
Mon, Oct 12, 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

Mon, Oct 12, 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.
Mon, Oct 12, 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?

Mon, Oct 12, 9:44 AM · Restricted Project

Sun, Oct 11

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?

Sun, Oct 11, 10:23 PM · Restricted Project

Sat, Oct 10

lxfind committed rG667dfe39caa0: [Coroutines] Refactor/Rewrite Spill and Alloca processing (authored by lxfind).
[Coroutines] Refactor/Rewrite Spill and Alloca processing
Sat, Oct 10, 10:23 PM
lxfind closed D88872: [Coroutines] Refactor/Rewrite Spill and Alloca processing.
Sat, Oct 10, 10:23 PM · Restricted Project
lxfind updated the diff for D88872: [Coroutines] Refactor/Rewrite Spill and Alloca processing.

address comments; rebase

Sat, Oct 10, 9:24 PM · Restricted Project
lxfind requested review of D89191: [ASAN] Make sure we are only processing lifetime markers with offset 0 to alloca.
Sat, Oct 10, 9:15 AM · Restricted Project

Fri, Oct 9

lxfind added a comment to D88872: [Coroutines] Refactor/Rewrite Spill and Alloca processing.

Thanks for your patch! It mentions some bugs about allocas we need to handle in the future.

For this patch, I'm little confusing about why we need to separate alloca from spills. In my mind, a spill means something we need to put in the frame. And an alloca which would be in the frame is naturally a spill.
I think the patch benefits from replacing

using SpillInfo = SmallVector<Spill, 8>;

to

using SpillInfo = SmallMapVector<Value *, SmallVector<Instruction *, 2>, 8>;

Thanks for taking a look at the patch. If you look at the implementation, the handling of "Spills" and always different from the handling of allocas. They do share the same concept that they need to go to the frame (which is why they both belong to FrameDataInfo).
The primary reason to separate them (and hence set up the code for future fixes), is this one primary difference between them: A Spill is a direct def-use relationship that crosses suspension points; while an alloca may not be exposed to a direct def-use relationship that crosses suspension points but still need to go to the frame. The condition for them to go to the frame is fundamentally different.

I agree with we can benefit from separating alloca from spills. At least we don't need extract allocas from spills by a redundant loop any more. After we separate allocas from spills, the name spills seems a little strange. But I think it doesn't really matter.

Here is a question about the bug mentioned in summary. I write a simple code like this:

void consuming(int* pa);

task escape_alloca() {
  int a;
  consuming(&a);
  co_await something();
}

But clang would still put a in the frame in O0 or O2. I guess it is because the def of a and the use of a is cross initial_suspend (in O0 mode) or the lifetime markers is cross the co_await something point. Is there anything wrong? Or what is the example about the bug?

Fri, Oct 9, 9:33 PM · Restricted Project
lxfind added inline comments to D88872: [Coroutines] Refactor/Rewrite Spill and Alloca processing.
Fri, Oct 9, 8:33 AM · Restricted Project
lxfind added a comment to D88872: [Coroutines] Refactor/Rewrite Spill and Alloca processing.

Thanks for your patch! It mentions some bugs about allocas we need to handle in the future.

For this patch, I'm little confusing about why we need to separate alloca from spills. In my mind, a spill means something we need to put in the frame. And an alloca which would be in the frame is naturally a spill.
I think the patch benefits from replacing

using SpillInfo = SmallVector<Spill, 8>;

to

using SpillInfo = SmallMapVector<Value *, SmallVector<Instruction *, 2>, 8>;
Fri, Oct 9, 8:32 AM · Restricted Project

Thu, Oct 8

lxfind requested review of D89066: [Coroutine][Sema] Only tighten the suspend call temp lifetime for final awaiter.
Thu, Oct 8, 1:10 PM · Restricted Project

Mon, Oct 5

lxfind requested review of D88872: [Coroutines] Refactor/Rewrite Spill and Alloca processing.
Mon, Oct 5, 11:11 PM · Restricted Project
lxfind abandoned D88871: [Coroutines] Refactor Spill and Alloca information.
Mon, Oct 5, 10:50 PM · Restricted Project
lxfind requested review of D88871: [Coroutines] Refactor Spill and Alloca information.
Mon, Oct 5, 10:48 PM · Restricted Project

Sep 25 2020

lxfind committed rGd2166076b882: [Coroutine] Split PHI Nodes in `cleanuppad` blocks in a way that obeys EH pad… (authored by dpaoliello).
[Coroutine] Split PHI Nodes in `cleanuppad` blocks in a way that obeys EH pad…
Sep 25 2020, 11:31 AM
lxfind closed D88059: [Coroutine] Split PHI Nodes in `cleanuppad` blocks in a way that obeys EH pad rules.
Sep 25 2020, 11:30 AM · Restricted Project
lxfind added a comment to D88059: [Coroutine] Split PHI Nodes in `cleanuppad` blocks in a way that obeys EH pad rules.

@lxfind Do you have commit permissions? If so, could you please merge this in?

Sep 25 2020, 11:11 AM · Restricted Project
lxfind added a comment to D88059: [Coroutine] Split PHI Nodes in `cleanuppad` blocks in a way that obeys EH pad rules.

@lxfind Do you have commit permissions? If so, could you please merge this in?

Sep 25 2020, 10:57 AM · Restricted Project

Sep 24 2020

lxfind added a comment to D87817: [LICM][Coroutine] Don't sink stores to coroutine suspend point..

We try to find an general solution to handle some conservative & mismatch analysis in transformations caused by the change of cfg with coro.suspend intrinsic. However afaik, it seems quiet difficult to deal this without change framework fo coroutine.
This patch just fixes the known issue, it may happens in other passes, FYI.

one of the idea is that we do not generate default case for switch instruction of coro.suspend intrinsic. Instead, we find fall through coro.end for coro.suspend directly in corosplit pass. The only uncertain thing is whether fall through coro.end is moved by passes which may change the semantic.

@lxfind, what do you think about this idea?

Are you suggesting to not have an edge from the coro.suspend switch to the coro.end block? Would that make the coro.end BB a dead BB and could potentially get removed?

No, There is always path from entry to coro.end BB.

This is likely the right solution, but we do need to make it more general. In order for this to always work, I wonder if the proper place to insert this transformation is in LoopSimplify, which is a pass always executed before any Loop pass. That might guarantee that any loop pass will be able to handle this properly. I am not too familiar with loop passes, but maybe someone else could comment on that.

Loop exit-block insertion in LoopSimplify pass guarantees that all exit blocks from the loop only have predecessors from inside of the loop. It will break the dedicated form of exit blocks when we consider ignore coro.suspend path. Maybe there is other idea i haven't thought about.

Sep 24 2020, 10:02 PM · Restricted Project
lxfind added inline comments to D87596: [Coroutines] Reuse storage for local variables with non-overlapping lifetimes.
Sep 24 2020, 10:35 AM · Restricted Project
lxfind added inline comments to D87596: [Coroutines] Reuse storage for local variables with non-overlapping lifetimes.
Sep 24 2020, 10:05 AM · Restricted Project
lxfind added inline comments to D87596: [Coroutines] Reuse storage for local variables with non-overlapping lifetimes.
Sep 24 2020, 10:03 AM · Restricted Project

Sep 23 2020

lxfind added a comment to D87817: [LICM][Coroutine] Don't sink stores to coroutine suspend point..

We try to find an general solution to handle some conservative & mismatch analysis in transformations caused by the change of cfg with coro.suspend intrinsic. However afaik, it seems quiet difficult to deal this without change framework fo coroutine.
This patch just fixes the known issue, it may happens in other passes, FYI.

one of the idea is that we do not generate default case for switch instruction of coro.suspend intrinsic. Instead, we find fall through coro.end for coro.suspend directly in corosplit pass. The only uncertain thing is whether fall through coro.end is moved by passes which may change the semantic.

@lxfind, what do you think about this idea?

Sep 23 2020, 9:13 PM · Restricted Project
lxfind added inline comments to D87596: [Coroutines] Reuse storage for local variables with non-overlapping lifetimes.
Sep 23 2020, 8:46 PM · Restricted Project

Sep 22 2020

lxfind accepted D88059: [Coroutine] Split PHI Nodes in `cleanuppad` blocks in a way that obeys EH pad rules.
Sep 22 2020, 2:08 PM · Restricted Project
lxfind added inline comments to D88059: [Coroutine] Split PHI Nodes in `cleanuppad` blocks in a way that obeys EH pad rules.
Sep 22 2020, 1:59 PM · Restricted Project
lxfind added inline comments to D88059: [Coroutine] Split PHI Nodes in `cleanuppad` blocks in a way that obeys EH pad rules.
Sep 22 2020, 11:30 AM · Restricted Project
lxfind accepted D87596: [Coroutines] Reuse storage for local variables with non-overlapping lifetimes.

Overall LGTM. Thank you for addressing the feedback!
One last thing, the optimization level code can be further simplified. Since you are obtaining the OptLevel from the PassManagerBuilder, which is an integer. I feel it would be easier if you just stick with an integer optlevel instead of converting it to OptimizationLevel. The reason OptimizationLevel exists is to be able to model both OptLevel and SizeLevel at the same time, but here you don't really care about the SizeLevel. So I would suggest just use an int for it and save all the trouble converting.

Sep 22 2020, 8:54 AM · Restricted Project
lxfind added inline comments to D87596: [Coroutines] Reuse storage for local variables with non-overlapping lifetimes.
Sep 22 2020, 8:47 AM · Restricted Project

Sep 21 2020

lxfind added inline comments to D87596: [Coroutines] Reuse storage for local variables with non-overlapping lifetimes.
Sep 21 2020, 11:43 PM · Restricted Project
lxfind added a comment to D87596: [Coroutines] Reuse storage for local variables with non-overlapping lifetimes.

Thanks for the improvements. I believe the implementation can still be cleaner:
Instead of passing all those parameters to the constructor of FrameTypeBuilder, we could:

  • Move all the implementation details into addFieldForAllocas function. We don't even need the NonOverlappedAllocaInfo class, all variables and the body of run() could go in there.
  • We can change the type of ForSpill member of Field from pointer to a SmallVector of Spill. That way, you can handle ForSpill universally without knowing whether this optimization was turned on or not.
Sep 21 2020, 5:21 PM · Restricted Project

Sep 18 2020

lxfind committed rG11453740bc6f: [ASAN] Properly deal with musttail calls in ASAN (authored by lxfind).
[ASAN] Properly deal with musttail calls in ASAN
Sep 18 2020, 11:11 PM
lxfind closed D87777: [ASAN] Properly deal with musttail calls in ASAN.
Sep 18 2020, 11:11 PM · Restricted Project

Sep 17 2020

lxfind added inline comments to D87596: [Coroutines] Reuse storage for local variables with non-overlapping lifetimes.
Sep 17 2020, 11:57 AM · Restricted Project
lxfind committed rG5b533d6cdeed: [Coroutine] Fix a bug where Coroutine incorrectly spills phi and invoke defs… (authored by lxfind).
[Coroutine] Fix a bug where Coroutine incorrectly spills phi and invoke defs…
Sep 17 2020, 8:13 AM
lxfind closed D87810: [Coroutine] Fix a bug where Coroutine incorrectly spills phi and invoke defs before CoroBegin.
Sep 17 2020, 8:13 AM · Restricted Project

Sep 16 2020

lxfind updated the diff for D87810: [Coroutine] Fix a bug where Coroutine incorrectly spills phi and invoke defs before CoroBegin.

fix lint

Sep 16 2020, 7:14 PM · Restricted Project
lxfind requested review of D87810: [Coroutine] Fix a bug where Coroutine incorrectly spills phi and invoke defs before CoroBegin.
Sep 16 2020, 6:26 PM · Restricted Project
lxfind added inline comments to D87777: [ASAN] Properly deal with musttail calls in ASAN.
Sep 16 2020, 5:34 PM · Restricted Project
lxfind updated the diff for D87777: [ASAN] Properly deal with musttail calls in ASAN.

fix test

Sep 16 2020, 10:38 AM · Restricted Project
lxfind updated the diff for D87777: [ASAN] Properly deal with musttail calls in ASAN.

add test

Sep 16 2020, 10:34 AM · Restricted Project
lxfind updated the diff for D87777: [ASAN] Properly deal with musttail calls in ASAN.

comments

Sep 16 2020, 10:33 AM · Restricted Project
lxfind requested review of D87777: [ASAN] Properly deal with musttail calls in ASAN.
Sep 16 2020, 10:26 AM · Restricted Project

Sep 15 2020

lxfind committed rG7b4cc0961b14: [TSAN] Handle musttail call properly in EscapeEnumerator (and TSAN) (authored by lxfind).
[TSAN] Handle musttail call properly in EscapeEnumerator (and TSAN)
Sep 15 2020, 3:21 PM
lxfind closed D87620: [TSAN] Handle musttail call properly in EscapeEnumerator (and TSAN).
Sep 15 2020, 3:21 PM · Restricted Project
lxfind added a comment to D87470: [Coroutine][Sema] Tighten the lifetime of symmetric transfer returned handle.

@lxfind , could you backport this to branch 11?

Sep 15 2020, 11:12 AM · Restricted Project

Sep 14 2020

lxfind added inline comments to D87596: [Coroutines] Reuse storage for local variables with non-overlapping lifetimes.
Sep 14 2020, 9:22 PM · Restricted Project
lxfind added inline comments to D87596: [Coroutines] Reuse storage for local variables with non-overlapping lifetimes.
Sep 14 2020, 8:20 PM · Restricted Project
lxfind added a comment to D87596: [Coroutines] Reuse storage for local variables with non-overlapping lifetimes.

Thank you for working on this optimization!

This type of optimizations is typically not enabled in O0, and we probably don't want to either. Should we gate it under the optimization level?

This optimization depends on lifetime markers, which would not be produced in O0. So this optimization won't be enabled in O0.

Sep 14 2020, 8:04 PM · Restricted Project
lxfind committed rG1f837265eb08: [Coroutines] Fix a typo in documentation (authored by lxfind).
[Coroutines] Fix a typo in documentation
Sep 14 2020, 7:47 PM
lxfind closed D83563: [Coroutines] Fix a typo in documentation.
Sep 14 2020, 7:47 PM · Restricted Project
lxfind added reviewers for D83563: [Coroutines] Fix a typo in documentation: rjmccall, wenlei, junparser, ChuanqiXu.
Sep 14 2020, 1:20 PM · Restricted Project
lxfind updated the diff for D83563: [Coroutines] Fix a typo in documentation.

rebase

Sep 14 2020, 1:19 PM · Restricted Project
lxfind added a comment to D87596: [Coroutines] Reuse storage for local variables with non-overlapping lifetimes.

Thank you for working on this optimization!

Sep 14 2020, 1:12 PM · Restricted Project
lxfind added inline comments to D87620: [TSAN] Handle musttail call properly in EscapeEnumerator (and TSAN).
Sep 14 2020, 12:54 PM · Restricted Project
lxfind added inline comments to D87620: [TSAN] Handle musttail call properly in EscapeEnumerator (and TSAN).
Sep 14 2020, 12:43 PM · Restricted Project
lxfind updated the diff for D87620: [TSAN] Handle musttail call properly in EscapeEnumerator (and TSAN).

fix test failures

Sep 14 2020, 12:41 PM · Restricted Project
lxfind requested review of D87620: [TSAN] Handle musttail call properly in EscapeEnumerator (and TSAN).
Sep 14 2020, 10:12 AM · Restricted Project

Sep 11 2020

lxfind committed rGdf477db5f9e0: [Coroutine][Sema] Tighten the lifetime of symmetric transfer returned handle (authored by lxfind).
[Coroutine][Sema] Tighten the lifetime of symmetric transfer returned handle
Sep 11 2020, 1:36 PM
lxfind closed D87470: [Coroutine][Sema] Tighten the lifetime of symmetric transfer returned handle.
Sep 11 2020, 1:36 PM · Restricted Project
lxfind added a comment to D87470: [Coroutine][Sema] Tighten the lifetime of symmetric transfer returned handle.

Thanks, LGTM.

Sep 11 2020, 1:33 PM · Restricted Project
lxfind updated the diff for D87470: [Coroutine][Sema] Tighten the lifetime of symmetric transfer returned handle.

remove asan option, not needed

Sep 11 2020, 1:22 PM · Restricted Project
lxfind updated the summary of D87470: [Coroutine][Sema] Tighten the lifetime of symmetric transfer returned handle.
Sep 11 2020, 1:19 PM · Restricted Project
lxfind updated the diff for D87470: [Coroutine][Sema] Tighten the lifetime of symmetric transfer returned handle.

Add test to verify that lifetime.end appears right after the address call.

Sep 11 2020, 1:17 PM · Restricted Project
lxfind updated the diff for D87470: [Coroutine][Sema] Tighten the lifetime of symmetric transfer returned handle.

Remove unstable test

Sep 11 2020, 9:51 AM · Restricted Project
lxfind added a comment to D87470: [Coroutine][Sema] Tighten the lifetime of symmetric transfer returned handle.

hmm @rjmccall, I don't think there is a stable way to test this. The code generated for symmetric transfer is way too complicated to stably pattern match one less item in the frame.

Sep 11 2020, 9:49 AM · Restricted Project

Sep 10 2020

lxfind updated the diff for D87470: [Coroutine][Sema] Tighten the lifetime of symmetric transfer returned handle.

Add test case. Verify that the size of the frame reduced by 8.

Sep 10 2020, 11:37 PM · Restricted Project
lxfind added a comment to D87470: [Coroutine][Sema] Tighten the lifetime of symmetric transfer returned handle.

Thanks for the change. LGTM, and testcase?

Sep 10 2020, 9:48 PM · Restricted Project
lxfind requested review of D87470: [Coroutine][Sema] Tighten the lifetime of symmetric transfer returned handle.
Sep 10 2020, 10:27 AM · Restricted Project

Sep 8 2020

lxfind committed rG59a467ee4fae: [Coroutine] Make dealing with alloca spills more robust (authored by lxfind).
[Coroutine] Make dealing with alloca spills more robust
Sep 8 2020, 11:10 AM
lxfind closed D86859: [Coroutine] Make dealing with alloca spills more robust.
Sep 8 2020, 11:10 AM · Restricted Project
lxfind added inline comments to D86859: [Coroutine] Make dealing with alloca spills more robust.
Sep 8 2020, 9:52 AM · Restricted Project
lxfind updated the diff for D86859: [Coroutine] Make dealing with alloca spills more robust.

rebase before land

Sep 8 2020, 9:23 AM · Restricted Project
lxfind added inline comments to D86859: [Coroutine] Make dealing with alloca spills more robust.
Sep 8 2020, 9:06 AM · Restricted Project

Sep 4 2020

lxfind added inline comments to D86859: [Coroutine] Make dealing with alloca spills more robust.
Sep 4 2020, 9:12 PM · Restricted Project
lxfind updated the diff for D86859: [Coroutine] Make dealing with alloca spills more robust.

address typo

Sep 4 2020, 5:37 PM · Restricted Project
lxfind added inline comments to D86859: [Coroutine] Make dealing with alloca spills more robust.
Sep 4 2020, 11:13 AM · Restricted Project