Alina Sbirlea via llvm-dev
2020-Feb-10 19:34 UTC
[llvm-dev] RFC: Mark BasicAA as a CFG-only pass.
Hi, I'd like to understand if it makes sense to keep BasicAA as a not CFG-only pass, or if it can be updated to CFG-only. The change was made in D44564 <https://reviews.llvm.org/D44564>.>From what I gathered the motivation was PhiValuesAnalysis not beingproperly updated, and BasicAA having an instance of it. PhiValuesAnalysis now uses callback values to invalidate deleted values ( r340613 <https://reviews.llvm.org/rL340613>), PhiValuesAnalysis is also being updated in MemDepAnalysis (D48489 <https://reviews.llvm.org/D48489>) and BasicAA is invalidated if PhiValuesAnalysis gets invalidated. I may not have the full context here, so I'd like some feedback: does it make sense to make BasicAA a CFG-only pass again? Thank you, Alina -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200210/1f57ad9e/attachment.html>
Alina Sbirlea via llvm-dev
2020-Feb-10 20:35 UTC
[llvm-dev] RFC: Mark BasicAA as a CFG-only pass.
Hi, Here's a tentative patch of the changes for this: D74353 <https://reviews.llvm.org/D74353>. Thank you, Alina On Mon, Feb 10, 2020 at 11:34 AM Alina Sbirlea <alina.sbirlea at gmail.com> wrote:> Hi, > > I'd like to understand if it makes sense to keep BasicAA as a not CFG-only > pass, or if it can be updated to CFG-only. The change was made in D44564 > <https://reviews.llvm.org/D44564>. > > From what I gathered the motivation was PhiValuesAnalysis not being > properly updated, and BasicAA having an instance of it. > PhiValuesAnalysis now uses callback values to invalidate deleted values ( > r340613 <https://reviews.llvm.org/rL340613>), PhiValuesAnalysis is also > being updated in MemDepAnalysis (D48489 <https://reviews.llvm.org/D48489> > ) and BasicAA is invalidated if PhiValuesAnalysis gets invalidated. > > I may not have the full context here, so I'd like some feedback: does it > make sense to make BasicAA a CFG-only pass again? > > Thank you, > Alina >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200210/7c01ced4/attachment.html>
Hal Finkel via llvm-dev
2020-Feb-10 21:48 UTC
[llvm-dev] RFC: Mark BasicAA as a CFG-only pass.
On 2/10/20 2:35 PM, Alina Sbirlea wrote:> Hi, > > Here's a tentative patch of the changes for this: D74353 > <https://reviews.llvm.org/D74353>.I suppose that, as expected, it's invalidated less often this way. Given that it's generally stateless, does this really represent a cost savings? -Hal> > Thank you, > Alina > > > On Mon, Feb 10, 2020 at 11:34 AM Alina Sbirlea > <alina.sbirlea at gmail.com <mailto:alina.sbirlea at gmail.com>> wrote: > > Hi, > > I'd like to understand if it makes sense to keep BasicAA as a not > CFG-only pass, or if it can be updated to CFG-only. The change was > made in D44564 <https://reviews.llvm.org/D44564>. > > From what I gathered the motivation was PhiValuesAnalysis not > being properly updated, and BasicAA having an instance of it. > PhiValuesAnalysis now uses callback values to invalidate deleted > values (r340613 > <https://reviews.llvm.org/rL340613>),PhiValuesAnalysis is also > being updated in MemDepAnalysis (D48489 > <https://reviews.llvm.org/D48489>) and BasicAA is invalidated if > PhiValuesAnalysis gets invalidated. > > I may not have the full context here, so I'd like some feedback: > does it make sense to make BasicAA a CFG-only pass again? > > Thank you, > Alina >-- Hal Finkel Lead, Compiler Technology and Programming Languages Leadership Computing Facility Argonne National Laboratory -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200210/c01de515/attachment.html>
Reasonably Related Threads
- RFC: Mark BasicAA as a CFG-only pass.
- [RFC] Switching to MemorySSA-backed Dead Store Elimination (aka cross-bb DSE)
- [RFC] Switching to MemorySSA-backed Dead Store Elimination (aka cross-bb DSE)
- Expose aliasing information in getModRefInfo (or viceversa?)
- Turning on MemorySSA for loop passes