This is an archive of the discontinued LLVM Phabricator instance.

[ValueLattice] Allocate value lattice elements on a pool (WIP)
Needs RevisionPublic

Authored by nikic on Jun 14 2020, 11:38 AM.

Details

Reviewers
fhahn
Summary

This introduces a uniqued, bump-pointer allocated pool of value lattice elements. ValueLatticeElement is still used directly for some temporaries, but the persisted values are fetched from the pool and represented as const ValueLatticeElement *.

I think this has a couple of advantages:

  • This should use less memory, as each distinct value lattice element is only stored once.
  • As a consequence, LVI no longer needs to store overdefined values separately, as storing everything directly is now cheap.
  • SCCP will no longer have to worry about invalidating references to value lattice elements.

This patch only has the LVI portion of the change (and there's probably some optimization potential there). For SCCP the main extra thing to handle would be the NumRangeExtensions, which would have to be moved into a separate value->int map under this model.

Preliminary compile-time numbers are a small improvement: https://llvm-compile-time-tracker.com/compare.php?from=862db369f8a8c543735c475ed05cf512846c3868&to=4388725f333c69cf29724528405038f8e143e579&stat=instructions

Diff Detail

Event Timeline

nikic created this revision.Jun 14 2020, 11:38 AM
Herald added a project: Restricted Project. · View Herald TranscriptJun 14 2020, 11:38 AM

Hm, migrating SCCP to this model might be harder than I initially thought, because it uses in-place modification so much.

Interesting, thanks for working on this!

This introduces a uniqued, bump-pointer allocated pool of value lattice elements. ValueLatticeElement is still used directly for some temporaries, but the persisted values are fetched from the pool and represented as const ValueLatticeElement *.

It would be interesting how many duplicated elements are actually eliminated. Using a single element for undef/unknown/overdefiened is definitely very profitable, as most lattice values probably end up overdefined. Removing the overdefined set in LVI is definitely a nice thing and SCCP currently does not have anything similar, so there should be a clear benefit there.

For constant/constantrange I am not sure if the extra book-keeping is actually worth it. Without deduplication, we should be able to get rid of the extra sets/maps. Also, SCCP currently updates the lattice elements directly, so caching them might be problematic (or we might have to allocate new objects for each state change?).

Unless there are large savings from the de-duplication, starting out with only de-duplicating overdefined for both SCCP and LVI, together with the bump allocator without de-duplication. That would be quite straight-forward and should be a clear benefit, at least for SCCP. Not sure if uniquing undef/unknown would be beneficial for SCCP, given the amount of code changes that would be needed.

https://llvm-compile-time-tracker.com/compare.php?from=862db369f8a8c543735c475ed05cf512846c3868&to=4388725f333c69cf29724528405038f8e143e579&stat=instructions

It looks like there are a few max-rss regressions? Is that noise?

Another thing to consider might be using a bump-allocator for ConstantRange and then using ConstantRange* to reduce the total size of ValueLatticeElement.

fhahn requested changes to this revision.Sep 18 2020, 5:58 AM

(marking as changes requested to indicate that there's an outstanding comment to clear up review queue)

This revision now requires changes to proceed.Sep 18 2020, 5:58 AM