Right. If we manually LICM'ed the load/stores in group 1 and group2 (with something like sum_i),
we will see the higher register pressure. Further, if we intentionally insert dead stores to store
the intermediate sum_is, the register pressure can be lowered. Some later passes should be responsible.

We see a big performance regression caused by this patch due to register pressure increase.
We found that remove stores in the same iteration could increase
the register pressure dramatically. In the following piece of code, group 1 and group 2 stores
are eliminated and the register usage increased from 70 to 171. This is from our
critical application, I am not sure whether this DSE could estimate RP?

Fix LIT failures.

Make a few changes based on comments, Thanks!

The issue has been workarounded by https://reviews.llvm.org/D94107
So abandon this one.

Add a new test case.

Change store to any instructions that may write to memory.

In D84873#2358999, @arsenm wrote:

In D84873#2357528, @cfang wrote:

Ping!

Should we commit this patch to fix the compilation time for now? Then we may look at the possibility to replace
MemoryDependenceAnaysis in AnnotateUniform pass?

This doesn't sound like a commitment to me

Should we commit this patch to fix the compilation time for now? Then we may look at the possibility to replace
MemoryDependenceAnaysis in AnnotateUniform pass?

In D89095#2325539, @nhaehnle wrote:

Why does this require a commit upstream?

In D89095#2325401, @nhaehnle wrote:

I agree with Matt here. You should be able to do experiments locally. Perhaps sinking should be disabled entirely, or perhaps sinking should be improved to take register liveness into account.

remove checking for findNearestCommonDominator failures.

In D89095#2322548, @arsenm wrote:

Just adding another flag isn't really fixing anything

Ping. Is there any further suggestions to move this patch ahead? Thanks.

A minor change to use the register directly in stead of getting it from the instruction.

Update based on the reviewers' request to generate the waterfall loop for resource registers of
arbitrary sizes.

In D84873#2186018, @arsenm wrote:

How much improvement does D84890 give vs. this?

Rebase after https://reviews.llvm.org/D84890

1. Add a missing space;
2. Early exit when it is not an EntryFunction.

In D84873#2182944, @asbirlea wrote:

In D84873#2182544, @arsenm wrote:

Does MemorySSA have the same problem? Could we just switch this to use MemorySSA?

Disclaimer: I know nothing about this pass or the purpose of this patch, just trying to answer this question.
MemorySSA has its own internal threshold limiting the number of memory instructions that are traversed upwards. It does not care at how many blocks those memory instructions are spread over.

https://reviews.llvm.org/D84873 addresses the same issue. So this is no longer needed.

This is no longer needed.

In D82603#2119746, @nhaehnle wrote:

Could you make this generic over the VGPR register class instead? That code duplication is rather annoying.

Add waterloop tests, and update existing tests.

Add a test. Thanks!

-ffast-math flag got lost in the Builder after this change.

LGTM

commit 2531535984ad989ce88aeee23cb92a827da6686e
Author: Changpeng Fang <changpeng.fang@gmail.com>
Date: Thu Jan 23 16:57:43 2020 -0800

Fix the LIT test failures.
(Yes, I messed up with a release build check, Thanks for catching these).

Where are these failing LIT tests located? I did LIT tests before posting for review and also before integrating.
Maybe my check is incomplete. Thanks.

Updated based on feedback:

Rename a few functions and variables:

update based on comment.

Update based on feedback: