This is an archive of the discontinued LLVM Phabricator instance.

Scheduler / Regalloc: use unique_ptr[] instead of std::vector
ClosedPublic

Authored by escha on Sep 25 2015, 5:28 PM.

Details

Summary

std::vector.resize() is actually about 2-3x slower than using unique_ptr, at least for me; it doesn't compile to bzero because the resize() in std:: consists of repeated appending (agh). On our out of tree target with a huge number of registers, this patch actually saves 1% of compile time. It should help significantly on AMDGPU as well, though likely a factor less due to them not having quite the same level of ridiculous register counts.

In general, we probably shouldn't use the heavyweight-ness of std::vector for constant-size arrays. There's really no reason to.

Diff Detail

Repository
rL LLVM

Event Timeline

escha updated this revision to Diff 35785.Sep 25 2015, 5:28 PM
escha retitled this revision from to Scheduler / Regalloc: use unique_ptr[] instead of std::vector.
escha updated this object.
escha added reviewers: MatzeB, arsenm, resistor.
escha set the repository for this revision to rL LLVM.
escha added a subscriber: llvm-commits.
MatzeB edited edge metadata.Sep 25 2015, 5:42 PM

Given that the vectors are fixed size I don't see why we would need the additional complexity of std::vector (it has to manage the size and capacity, ...). To me this change looks good with the nitpicks below addressed.

Of course it's bad that llvm doesn't get the vector initialisation optimized, but this is a separate issue, would you agree David?

lib/CodeGen/SelectionDAG/ScheduleDAGRRList.cpp
1221

This can be a simple SUnit * now.

1243–1246

This could use an ArrayRef<SUnit*> instead of std::unique_ptr reference + NumRegs.

escha added a comment.Oct 8 2015, 1:48 PM

Bumping this -- given that there doesn't seem to be any sign of LLVM properly optimizing this any time soon, is this optimization okay?

MatzeB accepted this revision.Oct 8 2015, 2:51 PM
MatzeB edited edge metadata.

Giving an official LGTM as my impression is that we are stuck with an imperfect optimizer and the work around here is easy enough. The nitpicks above still stand though.

This revision is now accepted and ready to land.Oct 8 2015, 2:51 PM
escha closed this revision.Dec 2 2015, 10:39 AM