This is an archive of the discontinued LLVM Phabricator instance.

[Assignment Tracking] Elide a map copy in some cases
ClosedPublic

Authored by Orlando on Feb 24 2023, 6:30 AM.

Details

Summary

Restructure AssignmentTrackingLowering::join to avoid a map copy in the case where BB has more than one pred.

We only need to perform a copy of a pred LiveOut if there's exactly one already-visited pred (Result = PredLiveOut). With more than one pred the result is built by calling Result = join(std::move(Result), PredLiveOut) for each subsequent pred, where join parameters are const &. i.e. with more than 1 pred we can avoid copying by referencing the first two pred LiveOuts in the first join and then using a move + reference for the rest.

This gives marginal gains in compile time for CTMark LTO-g builds (geomean reduction of 0.05% instructions retired).

Diff Detail

Event Timeline

Orlando created this revision.Feb 24 2023, 6:30 AM
Herald added a project: Restricted Project. · View Herald TranscriptFeb 24 2023, 6:30 AM
Herald added a subscriber: hiraditya. · View Herald Transcript
Orlando requested review of this revision.Feb 24 2023, 6:30 AM
Herald added a project: Restricted Project. · View Herald TranscriptFeb 24 2023, 6:30 AM

Broadly looks good, just a couple questions and a nit comment.

llvm/lib/CodeGen/AssignmentTrackingAnalysis.cpp
1777

visted->visited

1788

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.

1823–1824

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?

Could you add the context for review; also, are there any clear winners in CTMark that justify this change? 0.05% is close to noise, and the function complexity increases substantially.

Orlando planned changes to this revision.Mar 13 2023, 4:07 AM
Orlando marked 3 inline comments as done.

Could you add the context for review

Will do, sorry about that.

Are there any clear winners in CTMark that justify this change? 0.05% is close to noise, and the function complexity increases substantially.

Good question, -0.22% for tramp3d-v4 and -0.11% for mafft in that suite. However, it's probably worth me checking if the improvement is worth it after D145558.

llvm/lib/CodeGen/AssignmentTrackingAnalysis.cpp
1823–1824

Originally for line count / simplicity, but at this point it doesn't really make a difference. Changed.

Orlando updated this revision to Diff 505068.Mar 14 2023, 6:16 AM
Orlando marked an inline comment as done.

It actually looks like this is now more important with D145558 applied (around 0.24% difference). Here is the impact when this patch is reverted: http://llvm-compile-time-tracker.com/compare.php?from=baec5155d5e0c5d8cc0a2f51bd7fa14f785a0093&to=68d93a1c2d58990d7cd96f0b826b944fcc7d86f3&stat=instructions

+ Use ArrayRef.drop_front to get the preds vector "tail"
+ Reduce clutter of insertion code
+ Address nits

jmorse accepted this revision.Mar 23 2023, 3:00 AM

LGTM with a question; this does introduce knarlyness, so we should revisit this if we manage to make the pass faster.

llvm/lib/CodeGen/AssignmentTrackingAnalysis.cpp
1779–1780

To confirm my understanding: with no predecessors visited, there's no information in BlockInfo, and this attempts to place it in the live-in maps. If this block has already been visited then there can _only_ be an empty BlockInfo there already, so it's safe to use "try_emplace" and allow it to fail. Failure means the same BlockInfo is in the map, but we don't need to explore any further because there's been no change.

(I worry that try_emplace failing would cause exploration to cease too early, but if the above is true, then it's sound).

This revision is now accepted and ready to land.Mar 23 2023, 3:00 AM
Orlando marked an inline comment as done.Mar 27 2023, 1:59 AM

Thanks!

llvm/lib/CodeGen/AssignmentTrackingAnalysis.cpp
1779–1780

That's exactly right, yeah.

This revision was automatically updated to reflect the committed changes.
Orlando marked an inline comment as done.