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

[Hal Finkel]

----- Original Message -----
> From: "Chandler Carruth" <chandlerc at gmail.com>
> To: nlewycky at google.com, hfinkel at anl.gov
> Cc: llvm-commits at cs.uiuc.edu
> Sent: Tuesday, June 16, 2015 3:47:01 AM
> Subject: Re: [PATCH] [PM/AA] Split the location computation out of getArgLocation so the virtual interface on
> AliasAnalysis only deals with ModRef information.
> 
> 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.

Okay, so long as this is the plan of record, so to speak, let's move forward with this.

 -Hal

> 
> 
> ================
> 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/
> 
> 
> 

-- 
Hal Finkel
Assistant Computational Scientist
Leadership Computing Facility
Argonne National Laboratory