Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[AMDGPU] Do not preserve UniformityInfo #76696

Merged
merged 3 commits into from
Jan 2, 2024

Conversation

ssahasra
Copy link
Collaborator

@ssahasra ssahasra commented Jan 2, 2024

UniformityInfo has a transitive dependence on CycleInfo. A transform may change the CFG in trivial ways that do not affect uniformity, but that can leave cycles in a slightly inconsistent state. In the absence of updates to CycleInfo, it's cleaner to just invalidate both analyses.

This supersedes #76011, which tries to recompute CycleInfo when computing UniformityInfo.

UniformityInfo has a transitive dependence on CycleInfo. A transform may change
the CFG in trivial ways that do not affect uniformity, but that can leave cycles
in a slightly inconsistent state. In the absence of updates to CycleInfo, it's
cleaner to just invalidate both analyses.
@llvmbot
Copy link
Collaborator

llvmbot commented Jan 2, 2024

@llvm/pr-subscribers-llvm-adt

@llvm/pr-subscribers-backend-amdgpu

Author: Sameer Sahasrabuddhe (ssahasra)

Changes

UniformityInfo has a transitive dependence on CycleInfo. A transform may change the CFG in trivial ways that do not affect uniformity, but that can leave cycles in a slightly inconsistent state. In the absence of updates to CycleInfo, it's cleaner to just invalidate both analyses.

This supersedes #76011, which tries to recompute CycleInfo when computing UniformityInfo.


Full diff: https://github.com/llvm/llvm-project/pull/76696.diff

2 Files Affected:

  • (modified) llvm/lib/Target/AMDGPU/AMDGPURewriteUndefForPHI.cpp (-1)
  • (modified) llvm/lib/Target/AMDGPU/AMDGPUUnifyDivergentExitNodes.cpp (-3)
diff --git a/llvm/lib/Target/AMDGPU/AMDGPURewriteUndefForPHI.cpp b/llvm/lib/Target/AMDGPU/AMDGPURewriteUndefForPHI.cpp
index 459400e3359ca1..79e9312034da45 100644
--- a/llvm/lib/Target/AMDGPU/AMDGPURewriteUndefForPHI.cpp
+++ b/llvm/lib/Target/AMDGPU/AMDGPURewriteUndefForPHI.cpp
@@ -85,7 +85,6 @@ class AMDGPURewriteUndefForPHILegacy : public FunctionPass {
     AU.addRequired<DominatorTreeWrapperPass>();
 
     AU.addPreserved<DominatorTreeWrapperPass>();
-    AU.addPreserved<UniformityInfoWrapperPass>();
     AU.setPreservesCFG();
   }
 };
diff --git a/llvm/lib/Target/AMDGPU/AMDGPUUnifyDivergentExitNodes.cpp b/llvm/lib/Target/AMDGPU/AMDGPUUnifyDivergentExitNodes.cpp
index 9bc3ba161c9ebe..1bfb7c0edd80a9 100644
--- a/llvm/lib/Target/AMDGPU/AMDGPUUnifyDivergentExitNodes.cpp
+++ b/llvm/lib/Target/AMDGPU/AMDGPUUnifyDivergentExitNodes.cpp
@@ -109,9 +109,6 @@ void AMDGPUUnifyDivergentExitNodes::getAnalysisUsage(AnalysisUsage &AU) const {
     // FIXME: preserve PostDominatorTreeWrapperPass
   }
 
-  // No divergent values are changed, only blocks and branch edges.
-  AU.addPreserved<UniformityInfoWrapperPass>();
-
   // We preserve the non-critical-edgeness property
   AU.addPreservedID(BreakCriticalEdgesID);
 

@@ -85,7 +85,6 @@ class AMDGPURewriteUndefForPHILegacy : public FunctionPass {
AU.addRequired<DominatorTreeWrapperPass>();

AU.addPreserved<DominatorTreeWrapperPass>();
AU.addPreserved<UniformityInfoWrapperPass>();
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Probably should add an explanatory comment

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What would be the value of such a comment tucked away in some pass? Why only these specific passes? Why not others? We are just returning to the original state that we don't really know how to preserve UniformityAnalysis in general.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Mostly I'm worried about someone getting the idea again that this could be preserved. Feels like it should be documented somewhere, but there isn't a good place. Will anything break in a future change if this is re-added?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Will anything break in a future change if this is re-added?

Unfortunately we have never had a good way to diagnose this problem (preserving an analysis but not one of its transitive dependencies). I did once look at adding something to the legacy pass manager to detect it early (when adding passes instead of when running them) but never finished it.

@@ -109,9 +109,6 @@ void AMDGPUUnifyDivergentExitNodes::getAnalysisUsage(AnalysisUsage &AU) const {
// FIXME: preserve PostDominatorTreeWrapperPass
}

// No divergent values are changed, only blocks and branch edges.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ditto

/// NOTE: In general, no interface exists for a transform to update
/// (Machine)UniformityInfo. Additionally, (Machine)CycleAnalysis is a
/// transitive dependence, but it also does not provide an interface for
/// updation. Given that, transforms should not preserve uniformity in their
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

"updation" should be updating?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

"updation" should be a word! :-)

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I had looked it up ... "updation" is a word, and it's use as a noun is not wrong here. "updating" requires an object after it. But it was not clear to me if the verb "updating" is preferred over the noun "updation" in general ... so went with @arsenm's preference, writing it off as an ESL thing, and/or a tussle between en_US, en_UK and en_IN :)

@ssahasra ssahasra merged commit 4c2ad82 into llvm:main Jan 2, 2024
3 of 4 checks passed
@ssahasra ssahasra deleted the ssahasra/dont-preserve-uniformity branch January 2, 2024 08:16
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants