[PATCH] D86587: [WIP][Attributor] Per function iteration and memory tracking.

[Kuter Dinel via Phabricator via llvm-commits]

kuter added a comment.

In D86587#2238117 <https://reviews.llvm.org/D86587#2238117>, @sstefan1 wrote:

> Thanks for the explanation. Since the patch is not small and it is a WIP, can you add some more information about the failing tests? Maybe some specific examples?
>
> Merge checks are helpfull, but I guess if you give few specific examples with problems, it will be easier to focus. WDYT?

I wasn't sure of the issue, but I now think that there is a problem with the way things are manifested. 
I think there is a problem when we manifest a attribute without manifesting it's deps and this could happen with stub attributes.

We have to create "stub" (the name should change) AAs if we query for a deleted attribute.
I used to not update the "stub" attributes but know I do, maybe we can call them "duplicate".

The reason that we end up querying deleted AAs is because we don't seed every function interface AA.
We can reduce this significantly by changing the order that we iterate on functions.

Or we can also try keeping internal function AAs "alive" until we look at it's every caller(This would also fix the problem with call base context),
Of course this would increase the memory usage. This shouldn't be too hard because of the way I coded things.



================
Comment at: llvm/test/Transforms/Attributor/allow_list.ll:85
+; CHECK_ENABLED-NEXT:    [[TMP1:%.*]] = call i32 @range_test(i32 123)
 ; CHECK_ENABLED-NEXT:    ret i32 1
 ;
----------------
This could be a example to the manifest problem.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D86587/new/

https://reviews.llvm.org/D86587