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:

update based on feedback.

Update based on the comments.

Update based on feedback from the reviewer.

Implement rcp optimization for fdiv in AMGGPUCodegenPrepare to insert amdgcn_rcp intrinsic. For f32 type fdiv,
if fpmath metadata is unavailable, we could not do rcp optimization unless fast unsafe math is specified.

Introduce an intrinsic in AMDGPUCodeGenPrepare to generate correctly rounded fdiv32.

In D71293#1778867, @arsenm wrote:

The attribute should not de directly checked (we probably shouldn’t even be putting it on the function). The proper thing to check is the fpmath metadata on the individual instruction. This isn’t propagated into the DAG, so AMDGPUCodeGenPrepare inserts intrinsic calls which isn’t ideal

:
So what's your suggestion here? The current logic in AMDGPUCodeGenPrepare is to find cases that we can insert the intrinsic to generate "Faster 2.5 ULP division that does not support denormals."
Otherwise SIISelLowering will lower FDIV32 UnsafeMath and Demorm support.