When forgetting multiple SCEVs, rather than doing this one by one, we can
instead use mass updates. We plan to make them more efficient than they
are now, potentially improving compile time.
Details
Diff Detail
Event Timeline
This is an improvement in some cases, but less than I'd hoped: https://llvm-compile-time-tracker.com/compare.php?from=5e2c6abab42241c06680941be06fddcb9279e63d&to=18b24fb231b0dcbaf0dc304826974ac1aad77a01&stat=instructions
llvm/lib/Analysis/ScalarEvolution.cpp | ||
---|---|---|
7576 | We should be collecting these into a vector as well. | |
12813 | You can just pass S directly, no need to create SmallVector for single-element ArrayRef. |
I think we can do more of this kind, e.g. in forgetLoops. Will look into it more.
llvm/lib/Analysis/ScalarEvolution.cpp | ||
---|---|---|
7576 | Good point! |
Found some more places where it can be done. @nikic could you please check the CT now?
Updated version looks better: https://llvm-compile-time-tracker.com/compare.php?from=5e2c6abab42241c06680941be06fddcb9279e63d&to=82329ed73bb4100f3641703982cb661f77b95344&stat=instructions (don't mind SPASS, that's noise)
And here's both patches together: http://llvm-compile-time-tracker.com/compare.php?from=943b3048484b7e3cf04f4d51c23c82fcece2185d&to=82329ed73bb4100f3641703982cb661f77b95344&stat=instructions
llvm/lib/Analysis/ScalarEvolution.cpp | ||
---|---|---|
7494 | Just wondering, does the problem described in this comment affect the new invalidation mechanism? |
llvm/lib/Analysis/ScalarEvolution.cpp | ||
---|---|---|
7494 | If I'm reading this correctly, the new mechanism will drop trip count cache. The notion that we can sometimes forget something not for correctness purposes, but for the sole purpose of getting better results, is interesting. If it doesn't lead to any dangling pointers or directly wrong cached results, maybe we should consider non-recursive invalidation here. |
llvm/lib/Analysis/ScalarEvolution.cpp | ||
---|---|---|
7494 | Giving it some more thought, I think this one might be a source of bugs. Imagine that exit count depends on a hypothetical SCEV (not corresponding to any existing instruction directly) which, in turn, uses value being forgotten. When it is destroyed, how do we ensure that we'll not end up with exit count referencing (indirectly) a dangling pointer? |
Max, a suggestion review structure wise. If you flip the order of this patch and the one it's currently built on (i.e. by adding a forgetMemoizedResults arrayref wrapper), this can be easily landed as NFC. It won't really have any benefit compile time wise on it's own, but the change itself is not unreasonable. Inverting the review stack this way makes it easier to track the overall state of what's in review.
In fact, if you want to do that, you can consider this a conditional LGTM.
Two minor opportunities to exploit set invalidation for efficiency. I'll leave it to you whether these are worth separate review or not.
llvm/lib/Analysis/ScalarEvolution.cpp | ||
---|---|---|
12839 | There's an opportunity to exploit the invalidation of sets at a time here by replacing multiple walks, with one walk and a set membership check. | |
12849 | Same here. Though, I don't believe we have an set optimized contains_any already, so this might not be worth bothering with. |
llvm/lib/Analysis/ScalarEvolution.cpp | ||
---|---|---|
12839 | Good point, I'll try to make this in a follow-up. |
Just wondering, does the problem described in this comment affect the new invalidation mechanism?