Page MenuHomePhabricator
Feed Advanced Search

Wed, Oct 28

junparser added inline comments to D89768: [Coroutine] Properly determine whether an alloca should live on the frame.
Wed, Oct 28, 7:00 PM · Restricted Project
junparser added inline comments to D89768: [Coroutine] Properly determine whether an alloca should live on the frame.
Wed, Oct 28, 12:00 AM · Restricted Project

Tue, Oct 27

junparser accepted D89768: [Coroutine] Properly determine whether an alloca should live on the frame.

Thanks for the patch!

Tue, Oct 27, 11:44 PM · Restricted Project
junparser added inline comments to D89768: [Coroutine] Properly determine whether an alloca should live on the frame.
Tue, Oct 27, 11:36 PM · Restricted Project
junparser added inline comments to D89768: [Coroutine] Properly determine whether an alloca should live on the frame.
Tue, Oct 27, 11:16 PM · Restricted Project
junparser added inline comments to D89768: [Coroutine] Properly determine whether an alloca should live on the frame.
Tue, Oct 27, 11:05 PM · Restricted Project
junparser added inline comments to D89768: [Coroutine] Properly determine whether an alloca should live on the frame.
Tue, Oct 27, 11:01 PM · Restricted Project
junparser added inline comments to D89768: [Coroutine] Properly determine whether an alloca should live on the frame.
Tue, Oct 27, 10:52 PM · Restricted Project
junparser added inline comments to D89768: [Coroutine] Properly determine whether an alloca should live on the frame.
Tue, Oct 27, 7:27 PM · Restricted Project
junparser added a comment to D89768: [Coroutine] Properly determine whether an alloca should live on the frame.

Thank you for the explanation!

Tue, Oct 27, 7:25 PM · Restricted Project
junparser added inline comments to D89768: [Coroutine] Properly determine whether an alloca should live on the frame.
Tue, Oct 27, 8:00 AM · Restricted Project
junparser 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.

What do you mean by "leave aliases on frame"?

Just setEscaped for pointer cast used before coro.begin, or can we do something like llvm::PointerMayBeCapturedBefore to check the pointer directly? I'm not sure about this.

Tue, Oct 27, 7:53 AM · Restricted Project

Mon, Oct 26

junparser 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.

What do you mean by "leave aliases on frame"?

Mon, Oct 26, 11:36 PM · Restricted Project
junparser 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.

Mon, Oct 26, 7:17 AM · Restricted Project

Mon, Oct 12

junparser 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?

Unfortunately I don't. But this is not related to ASAN. Basically, this is causing destructing of objects that should still be alive. I suspect that it's because ExprWithCleanups always clean up temps that belongs to the full expression, not just the sub-expression in it.

Mon, Oct 12, 7:02 PM · Restricted Project
junparser 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.

Mon, Oct 12, 1:12 AM · Restricted Project

Sun, Oct 11

junparser 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, 7:25 PM · Restricted Project

Sep 28 2020

junparser planned changes to D87817: [LICM][Coroutine] Don't sink stores to coroutine suspend point..

@efriedma Consider that temporary fix maybe not the best solution for such issue. We would try to find other general solution. Before that, I'll keep this patch as plan changes.

Sep 28 2020, 5:21 PM · Restricted Project
junparser 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.

I wasn't referring to ignoring the coro.suspend path, but to move this code in this patch into the LoopSimplify pass, so that all loop passes can benefit, not sure if that makes sense. Anyway, I don't have a better idea.. So don't let that block you here.

Sep 28 2020, 5:12 PM · Restricted Project

Sep 27 2020

junparser accepted D87596: [Coroutines] Reuse storage for local variables with non-overlapping lifetimes.

LGTM, thanks for the patch!

Sep 27 2020, 11:00 PM · Restricted Project

Sep 26 2020

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

Sep 24 2020

junparser 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.

Sep 24 2020, 6:44 PM · Restricted Project

Sep 23 2020

junparser added a comment to D87596: [Coroutines] Reuse storage for local variables with non-overlapping lifetimes.

Please remove unnecessary headers include and declarations

Sep 23 2020, 8:28 PM · Restricted Project

Sep 22 2020

junparser 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.

Sep 22 2020, 11:27 PM · Restricted Project
junparser added a comment to D87817: [LICM][Coroutine] Don't sink stores to coroutine suspend point..

Can you please extend the testing to cover at least some of these cases: multiple predecesssors, multiple exit blocks, multiple predecessors with a coroutine switch?

Sep 22 2020, 8:12 PM · Restricted Project
junparser added inline comments to D87817: [LICM][Coroutine] Don't sink stores to coroutine suspend point..
Sep 22 2020, 8:08 PM · Restricted Project

Sep 21 2020

junparser updated the diff for D87817: [LICM][Coroutine] Don't sink stores to coroutine suspend point..
Sep 21 2020, 7:45 PM · Restricted Project
junparser updated the diff for D87817: [LICM][Coroutine] Don't sink stores to coroutine suspend point..

Update the doc. @efriedma is this ok?

Sep 21 2020, 7:30 PM · Restricted Project
junparser added a comment to D87817: [LICM][Coroutine] Don't sink stores to coroutine suspend point..

sorry for the late reply.

Sep 21 2020, 7:05 PM · Restricted Project

Sep 18 2020

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

If there are transformations that are specifically illegal with corouties, I'd like to see a section in https://llvm.org/docs/Coroutines.html describing what transforms are and are not legal. Just saying that the current version of the coroutine lowering code can't handle it isn't sufficient.

Sep 18 2020, 1:15 AM · Restricted Project

Sep 17 2020

junparser accepted D87810: [Coroutine] Fix a bug where Coroutine incorrectly spills phi and invoke defs before CoroBegin.

LGTM, Thanks for the fix.

Sep 17 2020, 3:11 AM · Restricted Project
junparser 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.

Sep 17 2020, 2:43 AM · Restricted Project
junparser 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.

Sep 17 2020, 1:56 AM · Restricted Project
junparser requested review of D87817: [LICM][Coroutine] Don't sink stores to coroutine suspend point..
Sep 17 2020, 1:44 AM · Restricted Project

Sep 15 2020

junparser added a reviewer for D87731: [Coro][NewPM] Handle llvm.coro.prepare.retcon in NPM coro-split pass: rjmccall.
Sep 15 2020, 7:37 PM · Restricted Project
junparser added a comment to D87731: [Coro][NewPM] Handle llvm.coro.prepare.retcon in NPM coro-split pass.

what does this intrinsic use for?

Sep 15 2020, 7:34 PM · Restricted Project
junparser 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, 12:44 AM · Restricted Project

Sep 14 2020

junparser accepted D83563: [Coroutines] Fix a typo in documentation.

LGTM, thanks!

Sep 14 2020, 6:55 PM · Restricted Project

Sep 10 2020

junparser 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, 6:46 PM · Restricted Project

Aug 24 2020

junparser abandoned D81549: [LVI] Make use of 'assume'-provided data-part1.
Aug 24 2020, 1:46 AM · Restricted Project

Aug 23 2020

junparser abandoned D86190: [LICM][Coroutine] Don't sink stores from loops with coro.suspend instructions..
Aug 23 2020, 6:36 PM · Restricted Project

Aug 19 2020

junparser added inline comments to D86190: [LICM][Coroutine] Don't sink stores from loops with coro.suspend instructions..
Aug 19 2020, 8:57 PM · Restricted Project
junparser added a comment to D86190: [LICM][Coroutine] Don't sink stores from loops with coro.suspend instructions..

Are you sure this is the right fix? At first glance, ensuring %p lives long enough seems like the sort of thing coroutine lowering should be able to deal with. If it isn't, at the very least we need documentation describing what optimizations are legal.

Aug 19 2020, 8:24 PM · Restricted Project

Aug 18 2020

junparser added a reviewer for D86190: [LICM][Coroutine] Don't sink stores from loops with coro.suspend instructions.: modocache.
Aug 18 2020, 11:13 PM · Restricted Project
junparser updated the summary of D86190: [LICM][Coroutine] Don't sink stores from loops with coro.suspend instructions..
Aug 18 2020, 8:01 PM · Restricted Project
junparser requested review of D86190: [LICM][Coroutine] Don't sink stores from loops with coro.suspend instructions..
Aug 18 2020, 8:00 PM · Restricted Project

Aug 17 2020

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

Looking at sample profile loader inline and your test case (either always inline or with sample profile), I'm guessing your change in the general llvm::getInlineCost was for sample profile loader inline, not CGSCC inline? If that's the case, it might be better to find a way to do this targeting just always inline and sample profile loader inline, then assert this shouldn't happen for CGSCC inline (would be a pass ordering bug).

Aug 17 2020, 6:50 PM · Restricted Project

Aug 5 2020

junparser accepted D85279: [Coroutines] Use `Value::stripPointerCasts` to collect lifetime marker of `alloca` in CoroFrame.
Aug 5 2020, 7:59 PM · Restricted Project
junparser added a comment to D85279: [Coroutines] Use `Value::stripPointerCasts` to collect lifetime marker of `alloca` in CoroFrame.

LGTM,Thank you, Please merge the testcases into one file.

Aug 5 2020, 2:33 AM · Restricted Project

Aug 3 2020

junparser abandoned D81544: [LVI] Make use of 'assume'-provided data.
Aug 3 2020, 6:35 PM · Restricted Project

Aug 2 2020

junparser closed D84137: [NFC][Coroutines] Update the comment in SemaCoroutine.cpp for the return type of await_suspend().
Aug 2 2020, 8:24 PM

Jul 23 2020

junparser accepted D84137: [NFC][Coroutines] Update the comment in SemaCoroutine.cpp for the return type of await_suspend().

LGTM, Thank you!

Jul 23 2020, 6:37 PM
junparser accepted D84135: [NFC][IR] add comments and a unit test for User::replaceUsesOfWith.

LGTM

Jul 23 2020, 6:36 PM · Restricted Project

Jul 9 2020

junparser committed rGf0bfad2ed9b4: [Coroutines] Refactor sinkLifetimeStartMarkers (authored by junparser).
[Coroutines] Refactor sinkLifetimeStartMarkers
Jul 9 2020, 3:24 AM
junparser closed D83379: [Coroutines] Refactor sinkLifetimeStartMarkers.
Jul 9 2020, 3:24 AM · Restricted Project

Jul 8 2020

junparser added inline comments to D83379: [Coroutines] Refactor sinkLifetimeStartMarkers.
Jul 8 2020, 7:31 PM · Restricted Project
junparser created D83379: [Coroutines] Refactor sinkLifetimeStartMarkers.
Jul 8 2020, 3:43 AM · Restricted Project

Jul 5 2020

junparser committed rG8849831d55a2: [Coroutines] Warning if return type of coroutine_handle::address is not void* (authored by ChuanqiXu).
[Coroutines] Warning if return type of coroutine_handle::address is not void*
Jul 5 2020, 10:47 PM
junparser closed D82442: [Coroutines] Warning if the return type of coroutine_handle::address is not void*.
Jul 5 2020, 10:47 PM · Restricted Project
junparser accepted D82442: [Coroutines] Warning if the return type of coroutine_handle::address is not void*.
Jul 5 2020, 8:47 PM · Restricted Project

Jul 3 2020

junparser added a comment to D82314: [Coroutines] Optimize the lifespan of temporary co_await object.

@lxfind This patch causes some mismatch when variable is used in both resume and destroy function. Besides, we should move this patch and the check in buildCoroutineFrame.

@lxfind, Would you try to fix this? If you do not have time, then I'll try do this. Thanks

Could you please help take a look, if you have a local repro? Thanks!

of course.

Jul 3 2020, 1:03 AM · Restricted Project, Restricted Project

Jul 1 2020

junparser added a comment to D82314: [Coroutines] Optimize the lifespan of temporary co_await object.

@lxfind This patch causes some mismatch when variable is used in both resume and destroy function. Besides, we should move this patch and the check in buildCoroutineFrame.

Jul 1 2020, 12:29 AM · Restricted Project, Restricted Project
junparser added a comment to D82314: [Coroutines] Optimize the lifespan of temporary co_await object.

@lxfind This patch causes some mismatch when variable is used in both resume and destroy function. Besides, we should move this patch and the check in buildCoroutineFrame.

Jul 1 2020, 12:29 AM · Restricted Project, Restricted Project

Jun 28 2020

junparser accepted D82314: [Coroutines] Optimize the lifespan of temporary co_await object.

LGTM, Thank you!

Jun 28 2020, 6:01 AM · Restricted Project, Restricted Project
junparser added a comment to D82442: [Coroutines] Warning if the return type of coroutine_handle::address is not void*.

This generally looks good to me. I'll accept this if others do not have different ideas about this. Thanks!

Jun 28 2020, 5:29 AM · Restricted Project

Jun 24 2020

junparser added a comment to D82314: [Coroutines] Optimize the lifespan of temporary co_await object.

@lxfind, Thank you! And could you please add some testcases?

Jun 24 2020, 1:02 AM · Restricted Project, Restricted Project

Jun 23 2020

junparser added a comment to D82314: [Coroutines] Optimize the lifespan of temporary co_await object.

Rather than doing it here, can we build await_resume call expression with MaterializedTemporaryExpr when expand the coawait expression. That's how gcc does.

There doesn't appear to be a way to do that in Clang. It goes from the AST to IR directly, and there needs to be a MaterializedTemporaryExpr to wrap the result of co_await. Could you elaborate on how this might be done in Clang?

Jun 23 2020, 7:59 PM · Restricted Project, Restricted Project
junparser added a comment to D82314: [Coroutines] Optimize the lifespan of temporary co_await object.

@rsmith Thanks. That's a good point. Do you know if there already exists optimization passes in LLVM that attempts to shrink the range of lifetime intrinsics? If so, I am curious why that does not help in this case. Or is it generally unsafe to move the lifetime intrinsics, and we could only do it here with specific context knowledge about coroutines.

I don't know for sure, but I would expect someone to have implemented such a pass already. Moving a lifetime start intrinsic later, past instructions that can't possibly reference the object in question, seems like it should always be safe and (presumably) should always be a good thing to do, and similarly for moving lifetime end markers earlier. It could be that such a pass exists but it is run too late in the pass pipeline, so the coroutine split pass doesn't get to take advantage of it.

Jun 23 2020, 7:26 PM · Restricted Project, Restricted Project

Jun 22 2020

junparser added a comment to D82314: [Coroutines] Optimize the lifespan of temporary co_await object.

Rather than doing it here, can we build await_resume call expression with MaterializedTemporaryExpr when expand the coawait expression. That's how gcc does.

Jun 22 2020, 6:17 PM · Restricted Project, Restricted Project
junparser added a comment to D82029: [Coroutines] Ensure co_await promise.final_suspend() does not throw.

Excellent, thank you! The test failures on the diff appear to be legitimate, they reproduce for me when I apply this patch to my local checkout and run ninja check-clang. Could you take a look?

This LGTM otherwise! Also adding @junparser in case they have any thoughts, if not I'll accept after the test failures are addressed, Thanks!

Jun 22 2020, 5:52 AM · Restricted Project

Jun 16 2020

junparser committed rG4a1776979fd8: [CodeGen][TLS] Set TLS Model for __tls_guard as well. (authored by junparser).
[CodeGen][TLS] Set TLS Model for __tls_guard as well.
Jun 16 2020, 5:34 PM
junparser closed D81543: [CodeGen][TLS] Set TLS Model for __tls_guard as well..
Jun 16 2020, 5:33 PM · Restricted Project

Jun 15 2020

junparser added a comment to D81543: [CodeGen][TLS] Set TLS Model for __tls_guard as well..

@aaron.ballman thanks for the review. I have updated the patch.

Jun 15 2020, 11:58 PM · Restricted Project
junparser updated the diff for D81543: [CodeGen][TLS] Set TLS Model for __tls_guard as well..

address the comments.

Jun 15 2020, 11:58 PM · Restricted Project

Jun 14 2020

junparser added a comment to D81543: [CodeGen][TLS] Set TLS Model for __tls_guard as well..

@rnk @aaron.ballman any comments?

Jun 14 2020, 6:07 PM · Restricted Project

Jun 11 2020

junparser added a comment to D81549: [LVI] Make use of 'assume'-provided data-part1.

@nikic @fhahn any comments on this?

Jun 11 2020, 6:10 PM · Restricted Project
junparser added a comment to D81543: [CodeGen][TLS] Set TLS Model for __tls_guard as well..

kindly ping~

Jun 11 2020, 6:10 PM · Restricted Project
junparser added a comment to D81544: [LVI] Make use of 'assume'-provided data.

since we still need discuss about the invoke of getValueInBlock, I'll split this patch into two parts.

I think this case could also be handled naturally by IPSCCP using PredicateInfo. Currently does only use range info from conditional branches, but I don't think there's any reason for not also using info from assume predicates, other than me not having time to implement it yet. If you want to give it a try, it would need to be added here: https://github.com/llvm/llvm-project/blob/master/llvm/lib/Transforms/Scalar/SCCP.cpp#L1243

Jun 11 2020, 4:50 AM · Restricted Project

Jun 10 2020

junparser created D81549: [LVI] Make use of 'assume'-provided data-part1.
Jun 10 2020, 4:52 AM · Restricted Project
junparser added a comment to D81544: [LVI] Make use of 'assume'-provided data.

since we still need discuss about the invoke of getValueInBlock, I'll split this patch into two parts.

Jun 10 2020, 4:20 AM · Restricted Project
junparser created D81544: [LVI] Make use of 'assume'-provided data.
Jun 10 2020, 2:41 AM · Restricted Project
junparser created D81543: [CodeGen][TLS] Set TLS Model for __tls_guard as well..
Jun 10 2020, 2:08 AM · Restricted Project
junparser updated the summary of D81543: [CodeGen][TLS] Set TLS Model for __tls_guard as well..
Jun 10 2020, 2:08 AM · Restricted Project

Jun 7 2020

junparser committed rGa0de3335edcf: [clang] Implement VectorType logic not operator. (authored by junparser).
[clang] Implement VectorType logic not operator.
Jun 7 2020, 6:07 PM
junparser closed D80979: [clang] Implement VectorType logic not operator..
Jun 7 2020, 6:07 PM · Restricted Project

Jun 4 2020

junparser updated the diff for D80979: [clang] Implement VectorType logic not operator..

address the comment.

Jun 4 2020, 8:23 PM · Restricted Project
junparser added inline comments to D80979: [clang] Implement VectorType logic not operator..
Jun 4 2020, 6:46 PM · Restricted Project

Jun 3 2020

junparser added inline comments to D80979: [clang] Implement VectorType logic not operator..
Jun 3 2020, 11:02 PM · Restricted Project
junparser updated the diff for D80979: [clang] Implement VectorType logic not operator..

address the comment.
hi @erichkeane, most of the function in vector-1.cpp are copied from ext-vector.c with vector type changed to gcc vector type, they should emit same ir. I add test7 and test8 which test logic operation of gcc vector type.

Jun 3 2020, 11:02 PM · Restricted Project
junparser added a comment to D80979: [clang] Implement VectorType logic not operator..

This patch implement the logic not operation of vector type. it keeps same behavior as gcc does (only allows in C++). I'll update the wrong testcases

Jun 3 2020, 9:25 PM · Restricted Project
junparser added inline comments to D80979: [clang] Implement VectorType logic not operator..
Jun 3 2020, 8:53 PM · Restricted Project
junparser added a comment to D80979: [clang] Implement VectorType logic not operator..

@erichkeane @aaron.ballman , kindly ping :)

Jun 3 2020, 6:45 PM · Restricted Project

Jun 1 2020

junparser created D80979: [clang] Implement VectorType logic not operator..
Jun 1 2020, 10:45 PM · Restricted Project

May 24 2020

junparser abandoned D79078: [VectorCombine] Leave reduction operation to SLP.
May 24 2020, 9:19 PM · Restricted Project

May 21 2020

junparser accepted D80236: [VectorCombine] position pass after SLP in the optimization pipeline rather than before.

LGTM

May 21 2020, 6:57 PM · Restricted Project

May 17 2020

junparser added a comment to D79078: [VectorCombine] Leave reduction operation to SLP.

I added slightly modified versions of the tests here with:
rG6211830fbabd
rG43017ceb7841

Because they are affected by a change that I split off from D79799:
rG81e9ede3a2db

Please rebase (although given what we've discussed here, I'm not sure how we want to solve the general problem of matching/transforming vector reductions).

May 17 2020, 7:41 PM · Restricted Project
junparser added a comment to D79078: [VectorCombine] Leave reduction operation to SLP.

I'll defer to @spatel, although i semi-weakly insist that adding such cut-offs is weird.
OTOH if this pass is taught to form such reductions we would have caught this regression for free,
because after D79799 we would have ended up in an endless combine loop here.

I agree that we need a phase ordering test - see llvm/test/Transforms/PhaseOrdering/X86/addsub.ll as an example test file that describes some expected handshake between vector-combine and other passes. Also, please commit the new test with complete baseline CHECK lines (use utils/update_test_checks.py), and then update the file to show the diffs in this review. Let me know if that's not clear.

Almost there - it should be next to the example test, not where it is now.

I also sympathize with trying to solve this here rather than SLP. One of the reasons vector-combine exists is because SLP became too hard to reason about. In hindsight, we should have created a separate pass for reductions - those are not traditional SLP concerns. Just my opinion. :)

I'm not sure what you have in mind here?
That *this* pass should also form such reductions?
Or that we should not disturb them after SLP formed them?
Or something else?

hi @lebedev.ri , sorry for the late response.
I have checked the reduction tree build in SLPVectorizer, for now it only support same operation. It seems we can revert the transformation when match reduction operation in matchAssociativeReduction. However, I don't think it is a good idea.

I'm having trouble parsing this response.
Are you saying that SLP can not be taught about this,
that it should not be taught about this or ???.

May 17 2020, 7:10 PM · Restricted Project

May 14 2020

junparser added a comment to D79078: [VectorCombine] Leave reduction operation to SLP.

hi @lebedev.ri , @spatel , kindly ping.

May 14 2020, 7:03 PM · Restricted Project

May 12 2020

junparser added a comment to D79078: [VectorCombine] Leave reduction operation to SLP.

hi @lebedev.ri , sorry for the late response.
I have checked the reduction tree build in SLPVectorizer, for now it only support same operation. It seems we can revert the transformation when match reduction operation in matchAssociativeReduction. However, I don't think it is a good idea.
Also the extra phase-ordering test shows that this patch has minimal impact. Except the first case which is vectorized by SLP, the other cases keep the same IR as before.

May 12 2020, 6:24 AM · Restricted Project
junparser updated the diff for D79078: [VectorCombine] Leave reduction operation to SLP.

update the testcase.

May 12 2020, 6:24 AM · Restricted Project