llvm dev - Aug 2007 - [LLVMdev] Choosing Alias Analysis

On Friday 10 August 2007 13:54, Devang Patel wrote:
> > Or is it sufficient than an Andersen's object is constructed and
> > that that
> > constitutes "availability?"
>
> What do you mean by "available" ? You are using quotes :)
"Available" as referenced by PassSupport.h:

/// RegisterAnalysisGroup - Register a Pass as a member of an analysis 
/// _group_.  Analysis groups are used to define an interface (which need not 
/// derive from Pass) that is required by passes to do their job.  Analysis 
/// Groups differ from normal analyses because any available implementation of 
/// the group will be used if it is available.
///
/// If no analysis implementing the interface is available, a default
/// implementation is created and added.  A pass registers itself as the 
/// default implementation by specifying 'true' as the third template
argument
/// of this class.
> > What happens if multiple alias analyses are
> > constructed?  Is the most-recently constructed one considered the
> > "available"
> > one?
>
> When alias info is invalidated, pass manager is responsible to
> reconstruct alias analysis before a pass that requires alias info is
> executed. If multiple alias analysis are constructed then non default
> alias analysis will get used and recreated as per need.
Yes, but which one gets used?
> Note, the goal of analysis group is to select desired analysis
> implementations during entire run of optimizer. I do [not] think it is
> designed to handle cases where during one instance of optimizer
> multiple instances of analysis implementations are used
> simultaneously. 
But this is the example Chris presented.
> However, this may work for limited case of one 
> default and one non-default analysis implementation but I think it
> will break down when multiple non-default analysis implementations
> are constructed.
Even if it's just one default and one non-default created, which one gets
used when AA is invalidated?  I gather the non-default one will be used
per your description above.

I don't need to be able to choose various different implementations of an
analysis group, I just need to be able to pick and and guarantee it will
always be used.  From our discussion, I think I can do that as long as I
tell the analysis group registrar which one I want by constructing it.

How does the analysis group registrar know when a non-default implementation
has been constructed?
> If a pass requires particular implementation explicitly, i.e
> addRequired<Andersens>() then pass manager will make it available
> irrespective of alias analysis group. However explicitly requiring an
> analysis pass defeats the purpose of analysis group.
Right..

At the moment I'm trying to do what Chris suggested and provide a
cl::opt for coalescers.  I've got about this far:

  llvm::cl::opt<
    llvm::RegisterCoalescer::Ctor,
    false,
    SomeParserToBeDefined >
  Coalescer("coalescer",
                      cl::init(/* Default analysis group constructor */),
                      cl::desc("Pick a coalescer: (default = fill this
in)"));

I can't use RegisterPassParser because it expects a function pass
constructor and the RegisterCoalescer interface is not a function pass.

The question I have is how to get this to interact properly with analysis
groups.  The existing coalescer has this:

  // Need to register with PassManager so getAnalysis works
  RegisterPass<SimpleRegisterCoalescing> 
  X("simple-register-coalescing",
    "Simple register coalescing to eliminate all possible register copies 
     (default RC impl)");

  // Declare that we implement the RegisterCoalescer interface
  RegisterAnalysisGroup<RegisterCoalescer, true/*The Default*/> V(X);

My new coalescer does this:

  // Need to register with PassManager so getAnalysis works
  RegisterPass<ConservativeCoalescing> 
  X("conservative-register-coalescing",
    "Conservative register coalescing to eliminate register copies without 
     introducing spills");

  // Declare that we implement the RegisterCoalescer interface
  RegisterAnalysisGroup<RegisterCoalescer> V(X);

I want to be able to pick a coalescer with
--coalescer=simple-register-coalescing 
or
--coalscer=conservative-register-coalescing

I can't use the bare -conservative-register-coalescing Pass option because
the
tool doesn't do the opt-like thing of registering every pass as a
command-line
argument.  It should not do so because we don't want to expose all that to
the
user.

So there are a number of questions I have to answer:

- How do I get at the default analysis group member to pass its constructor to 
  cl::init?

- How do I get the name of the default analysis group member to put in the
  description string?  Presumably this is easy if I can get to the default 
  analysis group member.

- How will this all interact with getAnalysis<RegisterCoalescer>?  How do
I
  inject the constructor selected by --coalescer back into the analysis group 
  so it knows to use that when getAnalysis<RegisterCoalescer> is called?

All these registration and manager classes are really confusing.  I think what 
I need to do is get at PassInfo::getNormalCtor and PassInfo::setNormalCtor
for the InterfaceInfo member of RegisterAnalysisGroup.  Unfortunately,
it's private and doesn't have an accessor.  So I will have to do some
hacking
if this is the right direction to go.

Where does the code that actually constructs the implementation of an
analysis group member live?  Where's the code that decides which
implementation of the analysis group to return to the caller of 
getAnalysis<SomeAnalysisGroup>?

Am I at least on the right track?  I still don't have a clue as to how to
get
the Pass or PassInfo for the default implementation of an analysis group
interface.

Perhaps an easier way is to just expose the -simple-register-coalescing
and -conservative-register-coalescing options to the user, but I don't know
how to do that on an individual pass bases.  opt just jams then all in with
PassNameParser.  PassNameParser.h makes reference to a FilteredPassNameParser
that sounds closer to what I want but I can't find the code for that 
anywhere.

                                                      -Dave

On Friday 10 August 2007 15:12, David Greene wrote:
> Perhaps an easier way is to just expose the -simple-register-coalescing
> and -conservative-register-coalescing options to the user, but I don't
know
> how to do that on an individual pass bases.  opt just jams then all in with
> PassNameParser.  PassNameParser.h makes reference to a
> FilteredPassNameParser that sounds closer to what I want but I can't
find
> the code for that anywhere.
I found a fairly elegant way to do this.  I implemented what I imagine 
FilteredPassNameParser would be.  If all goes well I'll post a patch for
discussion.

                                                 -Dave

On Friday 10 August 2007 17:55, David Greene wrote:
> On Friday 10 August 2007 15:12, David Greene wrote:
> > Perhaps an easier way is to just expose the
-simple-register-coalescing
> > and -conservative-register-coalescing options to the user, but I
don't
> > know how to do that on an individual pass bases.  opt just jams then
all
> > in with PassNameParser.  PassNameParser.h makes reference to a
> > FilteredPassNameParser that sounds closer to what I want but I
can't find
> > the code for that anywhere.
>
> I found a fairly elegant way to do this.  I implemented what I imagine
> FilteredPassNameParser would be.  If all goes well I'll post a patch
for
> discussion.
And here it is.  It seems to work well.  Should I commit it?

                                            -Dave

//===----------------------------------------------------------------------===//
// FilteredPassNameParser class - Make use of the pass registration
// mechanism to automatically add a command line argument to opt for
// each pass that satisfies a filter criteria.  Filter should return
// true for passes to be registered as command-line options.
//
template<typename Filter>
class FilteredPassNameParser : public PassNameParser {
private:
  Filter filter;

public:
  bool ignorablePassImpl(const PassInfo *P) const { return !filter(*P); }
};

//===----------------------------------------------------------------------===//
// PassArgFilter - A filter for use with PassNameFilterParser that only
// accepts a Pass whose Arg matches certain strings.
//
// Use like this:
//
// extern const char AllowedPassArgs[] = "-anders_aa -dse";
//
// static cl::list<
//   const PassInfo*,
//   bool,
//   FilteredPassNameParser<PassArgFilter<AllowedPassArgs> > >
// PassList(cl::desc("LLVM optimizations available:"));
//
// Only the -anders_aa and -dse options will be available to the user.
//
template<const char *Args>
class PassArgFilter {
public:
  bool operator()(const PassInfo &P) const {
    return std::strstr(Args, P.getPassArgument()) != 0;
  }
};