[LLVMdev] BasicAA unable to analyze recursive PHI nodes

[Tobias Edler von Koch]

I'm not seeing a noticeable impact, apart from the fact that you'll
see different behavior further down the pipeline due to better alias
information (it's quite a common pattern).

The typical case is the one shown below - a PHI node with two
incoming values. The first value (the recursive GEP) goes away. In its
place, a temporary GEP gets created. So the number of incoming values
to analyze is the same. The only additional overhead is the creation
and destruction of the temporary instruction.

Tobias

On Wed, 10 Jun 2015 22:44:41 +0000 Daniel Berlin <dberlin at dberlin.org>
wrote:

> What is the compile time impact?  Basic AA is supposed to be basic, not
> catch every case
> 
> On Wed, Jun 10, 2015, 3:33 PM Tobias Edler von Koch <tobias at codeaurora.org>
> wrote:
> 
> > On Tue, 2 Jun 2015 11:32:13 -0500 Tobias Edler von Koch
> > <tobias at codeaurora.org> wrote:
> >
> > > Hi all,
> > >
> > > I came across the following limitation in our BasicAliasAnalysis. This
> > > happens with the following IR pattern:
> > >
> > >   %x = phi [ %incptr, ... ] [ %var, ... ]
> > >   %incptr = getelementptr %x, 1
> > >
> > > We will basically always return MayAlias for %x and any other value
> > > because aliasPHI recurses on the first value and gives up.
> >
> > Patch now posted as http://reviews.llvm.org/D10368
> >
> > Tobias
> >
> > --
> > Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a
> > Linux Foundation Collaborative Project.
> > _______________________________________________
> > LLVM Developers mailing list
> > LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
> >



-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a
Linux Foundation Collaborative Project.