This is an archive of the discontinued LLVM Phabricator instance.

[wip][basicaa] look through phis and selects when searching for underlying object
AbandonedPublic

Authored by reames on Mar 8 2021, 12:15 PM.

Details

Reviewers
nikic
bollu
Summary

Warning: Code is a mess, not for real review. This is mostly for @nikic to take a look and tell me if I missed something fundamental.

Background:

  • DecomposeGEP needed to be in sync with getUnderlyingObject in a very fragile manner. However, I can't find any good reason for this. Simple recursing through the base of the decomposed gep gives us the same number of recursive calls, and it doesn't seem to matter if the underlying object search is ahead of the recursion. All it does is add a small constant amount of additional work per step, at worst.
  • We can often find a single underlying object, even after searching through a phi graph. The existing recursive phi handling is one instance of this (but done in the recursive step).
  • If we allow the underlying logic search to traverse phi graphs, even with small limits (e.g. 6) we find interesting cases.

@nikic - I'm mostly looking for a sanity check here. This feels "too easy". Have I managed to miss something fundamental here?

Diff Detail

Event Timeline

reames created this revision.Mar 8 2021, 12:15 PM
reames requested review of this revision.Mar 8 2021, 12:15 PM
Herald added a project: Restricted Project. · View Herald TranscriptMar 8 2021, 12:15 PM
nikic added a comment.Mar 9 2021, 7:43 AM

DecomposeGEP needed to be in sync with getUnderlyingObject in a very fragile manner. However, I can't find any good reason for this. Simple recursing through the base of the decomposed gep gives us the same number of recursive calls, and it doesn't seem to matter if the underlying object search is ahead of the recursion. All it does is add a small constant amount of additional work per step, at worst.

Yes, I believe this is just a historical leftover. It should be safe to not have these in sync.

What this patch does generally makes sense to me, but unfortunately the compile-time impact is fairly significant: https://llvm-compile-time-tracker.com/compare.php?from=e81d813717b2ef227c5b995057153d2cca027afb&to=5adf4f2dab6c553151b76929726959759e6bd8dd&stat=instructions The impact is somewhat unexpected to me -- the additional checks done here don't look expensive and tightly limited.

reames abandoned this revision.Sep 1 2021, 1:47 PM