[PATCH] D136320: [Assignment Tracking Analysis][1/*] Add analysis pass core

Orlando Cazalet-Hyams via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Wed Nov 16 04:02:23 PST 2022


Orlando added a comment.

In D136320#3870269 <https://reviews.llvm.org/D136320#3870269>, @nlopes wrote:

> Please avoid using UndefValue::get as much as possible as we are trying to get rid of undef. Please use PoisonValue whenever possible.
> Thank you!

Hi @nlopes. This patch is part of the series in which we agreed this could be addressed after landing the stack: https://reviews.llvm.org/D133293#inline-1286892. That is the next item on my TODO list and I plan to make the change for all debug info modes (rather than just this new one). Is that still okay with you?

---

Thanks @StephenTozer, I've made those changes.



================
Comment at: llvm/lib/CodeGen/AssignmentTrackingAnalysis.cpp:188-189
+  Variables.push_back(DebugVariable(nullptr, None, nullptr));
+  for (auto VarLoc : Builder->Variables)
+    Variables.emplace_back(VarLoc);
+}
----------------
StephenTozer wrote:
> Orlando wrote:
> > StephenTozer wrote:
> > > Is there a reason this couldn't be inserted with `.insert()`? The for-loop with `emplace_back` would only be necessary if `Variables` and `Builder->Variables` were different types I think, but I might be missing something.
> > They are indeed different types - `Variables` is a SmallVector and `Builder->Variables` is a `UniqueVector` (I figured there was no need in paying the additional memory overhead cost of a UniqueVector since we're done inserting elements at this point.
> Sorry, I meant the element types of the vectors - even for different vector types, I believe `Variables.insert(Variables.begin(), Builder->Variables.begin(), Builder->Variables.end());` should work - if not, then please ignore!
Aha, gotcha, thanks. Changed to use `append`.


================
Comment at: llvm/lib/CodeGen/AssignmentTrackingAnalysis.cpp:663
+  // Find markers linked to this alloca.
+  for (DbgAssignIntrinsic *DAI : Linked) {
+    if (DAI->getExpression()->getNumElements() != 0)
----------------
StephenTozer wrote:
> Just confirming, will this loop body be executed multiple times for the same variable if the base alloca is linked to multiple DbgAssignIntrinsics? I don't think it would result in any incorrectness if that is the case, since this loop body is idempotent, but it might slow things down a little and possibly spam `dbgs()` a bit.
Yeah it will. I think that having multiple identical dbg.assigns linked to an alloca is unlikely though - IMO it's not worth filtering them out.


================
Comment at: llvm/lib/CodeGen/AssignmentTrackingAnalysis.cpp:1235
+  SmallPtrSet<BasicBlock *, 16> Visited;
+  while (!Worklist.empty() || !Pending.empty()) {
+    // We track what is on the pending worklist to avoid inserting the same
----------------
StephenTozer wrote:
> Could remove the `!Pending.empty()` condition, since Pending is empty when we reach this loop and is asserted to be empty at the end of each iteration?
True, nice catch.


================
Comment at: llvm/lib/CodeGen/AssignmentTrackingAnalysis.cpp:1289-1291
+  for (auto Pair : InsertBeforeMap) {
+    auto &MapVec = Pair.second;
+    for (auto Pair : MapVec) {
----------------
StephenTozer wrote:
> Nit, shadowed variables here and in the "Insert the other DEFs" loop below (could use structured bindings?)
> could use structured bindings

Not for the outer loop as `first` isn't used & causes an unused variable warning. Will do for the second (this code was written before the move to C++17!).


================
Comment at: llvm/lib/CodeGen/AssignmentTrackingAnalysis.cpp:1319
+        assert(isa<AllocaInst>(VarLoc.V));
+        assert(Simple);
+        VarLoc.Expr = DIExpression::get(Fn.getContext(), None);
----------------
StephenTozer wrote:
> Nit: Normally not too bothered about having many asserts even when they seem obvious, but `assert(Simple)` probably isn't needed just a few statements down from `if (!Simple) { ...; continue; }`
I've added a comment - if you still think it should go then I'll remove it.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D136320/new/

https://reviews.llvm.org/D136320



More information about the llvm-commits mailing list