[PATCH] D144732: [Assignment Tracking] Elide a map copy in some cases
Stephen Tozer via Phabricator via llvm-commits
llvm-commits at lists.llvm.org
Tue Feb 28 04:35:59 PST 2023
StephenTozer added a comment.
Broadly looks good, just a couple questions and a nit comment.
================
Comment at: llvm/lib/CodeGen/AssignmentTrackingAnalysis.cpp:1777
- auto PredLiveOut = LiveOut.find(Pred);
- // Pred must have been processed already. See comment at start of this loop.
- assert(PredLiveOut != LiveOut.end());
+ // No preds visted yet.
+ if (VisitedPreds.empty()) {
----------------
visted->visited
================
Comment at: llvm/lib/CodeGen/AssignmentTrackingAnalysis.cpp:1788
+ if (CurrentLiveInEntry == LiveIn.end()) {
+ LiveIn[&BB] = PredLiveOut;
+ return /*Changed*/ true;
----------------
Tiny question - does using `LiveIn[&BB] = ...` here mean that an empty map will first be constructed in the `&BB` bucket before we assign to it? If that is the case it might be better to just use `insert` or `try_emplace` instead; don't think this is high impact either way.
================
Comment at: llvm/lib/CodeGen/AssignmentTrackingAnalysis.cpp:1823-1824
// (expensive check).
if (CurrentLiveInEntry == LiveIn.end() ||
BBLiveIn != CurrentLiveInEntry->second) {
LiveIn[&BB] = std::move(BBLiveIn);
----------------
I see that above for the single-visited-pred case you've split this `if` into two separate checks, so that you can use the found iterator `CurrentLiveInEntry` if it's valid. Since we're doing essentially the same thing here, would it make sense to use the same logic in both places, or is there a reason for the difference?
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D144732/new/
https://reviews.llvm.org/D144732
More information about the llvm-commits
mailing list