This is an archive of the discontinued LLVM Phabricator instance.

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

Authored by chandlerc on Jun 4 2015, 3:44 PM.

Details

Summary

This interface was both computing memory locations by using TLI and
other tricks to estimate the size of memory referenced by an operand,
and computing ModRef information through similar investigations. This
change narrows the scope of the virtual interface on AliasAnalysis
slightly.

Note that all of this code could live in BasicAA, and be done with
a single investigation of the argument, if it weren't for the fact that
the generic code in AliasAnalysis::getModRefBehavior for a callsite
calls into the virtual aspect of (now) getArgModRefInfo. An alternative
factoring would be to lift all of this generic logic up into BasicAA and
not have any other AAs reason about argument-specific ModRef info or
memory locations. But it isn't really clear that this is a strictly
better interface. Suggestions for a preferred factoring welcome.

Diff Detail

Event Timeline

chandlerc updated this revision to Diff 27154.Jun 4 2015, 3:44 PM
chandlerc retitled this revision from to [PM/AA] Split the location computation out of getArgLocation so the virtual interface on AliasAnalysis only deals with ModRef information..
chandlerc updated this object.
chandlerc edited the test plan for this revision. (Show Details)
chandlerc added reviewers: nlewycky, hfinkel.
chandlerc added a subscriber: Unknown Object (MLST).

Ping. Anyone up for this?

hfinkel edited edge metadata.Jun 13 2015, 1:17 AM

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'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?

lib/Analysis/MemoryLocation.cpp
93

Should this kind of thing live in TLI?

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.

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.

lib/Analysis/MemoryLocation.cpp
93

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. =[

  • Original Message -----

From: "Chandler Carruth" <chandlerc@gmail.com>
To: nlewycky@google.com, hfinkel@anl.gov
Cc: llvm-commits@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/
This revision was automatically updated to reflect the committed changes.