-
Notifications
You must be signed in to change notification settings - Fork 76
Support running different allocation analyses #2605
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
Support running different allocation analyses #2605
Conversation
Parametrize `Allocation::run` to support more runnning more allocation analyses, thus making the allocation analysis framework more easily extensible. `ModuleAllocation` instances are now obtained from a templated `get` static member function to propagate the analysis kind to use. Signed-off-by: victor-eds <[email protected]>
| explicit ModuleAllocation(ModuleOp moduleOp) | ||
| : CallGraph<Allocation>(moduleOp) { | ||
| walk<WalkOrder::PreOrder, WalkOrder::PostOrder>( | ||
| template <typename AllocationAnalysis = triton::AllocationAnalysis> | ||
| static ModuleAllocation get(ModuleOp moduleOp) { | ||
| ModuleAllocation res(moduleOp); | ||
| res.walk<WalkOrder::PreOrder, WalkOrder::PostOrder>( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Cannot have templated constructors like this, so this is a static member function now.
…ysis` This is just a copy of `mlir::triton::AllocationAnalysis` for now. Signed-off-by: victor-eds <[email protected]>
d3fe27b to
68bf33c
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do not review analysis implementation. This is a copy of Allocation.cpp.
|
Does this PR solves the issue about the allocation #2340 |
This is a first PR refactoring the code so we can modify freely and fix issues like that one and the ones I'm finding with my current FA work |
|
|
|
Just rebased and solved conflicts. Enabling auto-merge. |
intel#2605 introduced allocation analysis specialization downstream, but upstreaming lead to a different approach (triton-lang/triton#5070). This commit reverts residual changes to the analysis matching upstream's triton-lang/triton@deee78f. Signed-off-by: victor-eds <[email protected]>
#2605 introduced allocation analysis specialization downstream, but upstreaming lead to a different approach (triton-lang/triton#5070). This commit reverts residual changes to the analysis matching upstream's triton-lang/triton@deee78f. Closes #2825. Signed-off-by: victor-eds <[email protected]>
Each of the two commits in this PR should be reviewed separately.
08786ac: To be upstreamed. Extends memory allocation analysis infrastructure so the analysis to use can be configured.
d3fe27b: Downstream. Use an Intel-specific analysis. This is just a copy of the original for now, so, please, do not review the analysis implementation.
96a2e78 and cbfdaf9 should be part of the first commit. Will squash there when upstreaming.