[LLVMdev] Choosing Alias Analysis

Devang Patel dpatel at apple.com
Fri Aug 10 11:54:55 PDT 2007


On Aug 10, 2007, at 10:15 AM, David Greene wrote:

> However, what happens when alias analysis information gets  
> invalidated?
> Is Andersen's still "available" in the sense analysis groups use it?
>
> If not, it seems it would be tough to make sure Andersen's is always
> used everywhere that AliasAnalysis is asked for because there are  
> passes
> llvm runs without any command-line directive and those passes could
> invalidate AA.
>
> 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 :)

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

Note, the goal of analysis group is to select desired analysis  
implementations during entire run of optimizer. I do think it is  
designed to handle cases where during one instance of optimizer  
multiple instances of analysis implementations are used  
simultaneously. 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.

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.

-
Devang
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20070810/cf421fd5/attachment.html>


More information about the llvm-dev mailing list