[PATCH] [PM/AA] Split the location computation out of getArgLocation so the virtual interface on AliasAnalysis only deals with ModRef information.

[Chandler Carruth]

In http://reviews.llvm.org/D10259#187740, @hfinkel wrote:

> I want to make sure that I understand where we'd like this to go. So currently, suppose you have a language with a runtime library ( ;) ), it is currently possible to add a custom AA pass that will provide argument memory-location information for those library calls. With this refactoring, this seems no longer possible.


I suppose that is possible today.

> I'm unclear on where we'd like this information to live (AA, TLI, etc.), but I think we need the ability to add this information for known functions without modifying core LLVM code. If we had a proper extensibility scheme for TLI (which, IMHO, we need regardless), maybe TLI would be the more-natural place?


TLI certainly seems closer to the right place to do this.

Fundamentally, there is not one but two aspects of extending this.

First, there is the computation of what memory an argument to a function accesses (in any way). This lets us compute a memory location for that argument.

Second, there is the computation of what mod/ref behavior the call has for that memory location.

The second thing seems reasonable for a custom AA pass to provide (and indeed, this facility is preserved with my patch).

However, given that memory locations are readily used by APIs other than AliasAnalysis, it seems very awkward for AA to provide the extension point for describing the extent of memory touched by a library call.

The flip side of this is that TLI might become unpleasantly broad if it supports querying for all of the analysis specific information we might have on all of the library functions we might recognize. But generally, I'm more in favor of extensibility hooks for library calls in TLI than anywhere else.


================
Comment at: lib/Analysis/MemoryLocation.cpp:93
@@ +92,3 @@
+
+// FIXME: This code is duplicated with BasicAliasAnalysis and should be hoisted
+// to some common utility location.
----------------
hfinkel wrote:
> Should this kind of thing live in TLI?
Almost certainly. I mostly think we don't yet have a good system for extending TLI yet... Oh wait, yea, that's kinda the point. =[

http://reviews.llvm.org/D10259

EMAIL PREFERENCES
  http://reviews.llvm.org/settings/panel/emailpreferences/