This is an archive of the discontinued LLVM Phabricator instance.

[CallSite removal] Migrate all Alias Analysis APIs to use the newly minted `CallBase` class instead of the `CallSite` wrapper.
ClosedPublic

Authored by chandlerc on Dec 12 2018, 7:31 PM.

Details

Summary

This moves the largest interwoven collection of APIs that traffic in
CallSites. While a handful of these could have been migrated with
a minorly more shallow migration by converting from a CallSite to
a CallBase, it hardly seemed worth it. Most of the APIs needed to
migrate together because of the complex interplay of AA APIs and the
fact that converting from a CallBase to a CallSite isn't free in its
current implementation.

Out of tree users of these APIs can fairly reliably migrate with some
combination of .getInstruction() on the CallSite instance and
casting the resulting pointer. The most generic form will look like CS
-> cast_or_null<CallBase>(CS.getInstruction()) but in most cases there
is a more elegant migration. Hopefully, this migrates enough APIs for
users to fully move from CallSite to the base class. All of the
in-tree users were easily migrated in that fashion.

Note to reviewers:
Let me know if there is anything else folks would like to see in the commit log
to help folks pick up this change out-of-tree?

Diff Detail

Event Timeline

chandlerc created this revision.Dec 12 2018, 7:31 PM

MemorySSA changes LGTM, modulo one comment. Thanks!

llvm/lib/Analysis/MemorySSA.cpp
133

s/CallInst/CallBase/?

Fix a goof in original patch caught in review.

chandlerc marked 2 inline comments as done.Dec 15 2018, 11:56 PM
chandlerc added inline comments.
llvm/lib/Analysis/MemorySSA.cpp
133

Good catch, fixed!

chandlerc marked an inline comment as done.Dec 23 2018, 12:01 AM

Ping!

compnerd accepted this revision.Jan 1 2019, 11:39 AM
compnerd added a subscriber: compnerd.
compnerd added inline comments.
llvm/include/llvm/Analysis/MemoryDependenceAnalysis.h
400

Hmm, I realize that the QueryCall is used for an index via pointer, but, could we not take this by reference? This shouldn't be null ever, so the reference would be nicer.

484

Similar.

llvm/include/llvm/Analysis/MemoryLocation.h
234

Similar.

llvm/lib/Analysis/AliasSetTracker.cpp
472

I wish that we could use something like std::tie to unpack in the loop declaration as in C++17.

474

I think that using std::tie to unpack is nicer.

llvm/lib/Analysis/CaptureTracking.cpp
275

I think that std::tie is nicer.

llvm/lib/Transforms/IPO/FunctionAttrs.cpp
160

Why not convert this to a range based for loop:?

llvm/lib/Transforms/Scalar/GVN.cpp
440

Might be nice to make that down-cast to a CallBase explicit.

This revision is now accepted and ready to land.Jan 1 2019, 11:39 AM
chandlerc marked 7 inline comments as done.Jan 2 2019, 1:51 AM

Sorry for arguing on these...

llvm/include/llvm/Analysis/MemoryDependenceAnalysis.h
400

That would be inconsistent with the majority of this API. I personally prefer the style you are suggesting here, but I don't want to make *only* these parameters differ, and I don't want to try to move the entire API to references in this patch, so I think these should stay pointers for now.

llvm/include/llvm/Analysis/MemoryLocation.h
234

Same as above, see the rest of this API which takes pointers.

llvm/lib/Analysis/AliasSetTracker.cpp
472

I mean, me too.

474

I disagree once it has to be here.

It forces us to use 3 lines instead of 2, and to leave variables uninitialized. And the only duplicated code here is IdxArgPair. Plus we have useful methods here. I think, given the choices, std::tie is not an improvement (by a narrow margin), even though structured bindings when we have them will be a huge improvement.

llvm/lib/Analysis/CaptureTracking.cpp
275

As above. I'll keep them in sync.

llvm/lib/Transforms/IPO/FunctionAttrs.cpp
160

I was trying to make minimal changes as this is already a massive patch.

llvm/lib/Transforms/Scalar/GVN.cpp
440

That is exceedingly rare in LLVM code, and I don't know why we would o it here really... It doesn't seem to add any important information?

FYI, I chatted with compnerd on IRC and he's fine with this going in as-is based on the above responses. Submitting...

This revision was automatically updated to reflect the committed changes.