[llvm-dev] noalias parameter attribute not currently exploited by alias analysis?

[Hal Finkel via llvm-dev]

----- Original Message -----
> From: "Alex Bradbury" <asb at asbradbury.org>
> To: "Hal Finkel" <hfinkel at anl.gov>
> Cc: "llvm-dev" <llvm-dev at lists.llvm.org>
> Sent: Monday, November 9, 2015 9:21:03 AM
> Subject: Re: noalias parameter attribute not currently exploited by alias analysis?
> 
> On 9 November 2015 at 14:30, Hal Finkel <hfinkel at anl.gov> wrote:
> > Thanks for reporting this issue, and I apologize for the delayed
> > reply. It seems you've run into a limitation of the current
> > implementation, and please do file a bug report.
> >
> > If I take your IR, and run it through:
> >
> >   opt -basicaa -scoped-noalias -aa-eval -evaluate-aa-metadata
> >   -print-all-alias-modref-info -disable-output 2>&1 <
> >   /tmp/your/input.ll
> >
> > there seems to be a limitation with the way that pointer provenance
> > is determined. Looking at the mod/ref info, things quickly become
> > suboptimal:
> >
> >   NoAlias:   %4 = load i8, i8* %.04.prol, align 1, !tbaa !1 <->
> >     store i8 %11, i8* %.013.prol, align 1, !tbaa !1
> >   NoAlias:   %4 = load i8, i8* %.04.prol, align 1, !tbaa !1 <->
> >     store i8 %14, i8* %18, align 1, !tbaa !1
> >   NoAlias:   %4 = load i8, i8* %.04.prol, align 1, !tbaa !1 <->
> >     store i8 %17, i8* %19, align 1, !tbaa !1
> >   MayAlias:   %4 = load i8, i8* %.04.prol, align 1, !tbaa !1 <->
> >     store i8 %31, i8* %.013, align 1, !tbaa !1
> >   MayAlias:   %4 = load i8, i8* %.04.prol, align 1, !tbaa !1 <->
> >     store i8 %34, i8* %38, align 1, !tbaa !1
> >   ...
> >
> > it seems like looking through one PHI is okay, but as soon as we
> > need to look though both the PHI in the loop and also the PHI in
> > the preheader, we're unable to do so conclusively. This seems to
> > be the underlying problem.
> 
> Thanks for confirming I'm not missing anything obvious here. I'll
> file
> an issue later today.

Great, thanks!

> 
> I don't suppose you had any thoughts on the 'Unknown' dependencies
> reported in -print-memdeps? Their occurrence seems rather mysterious
> to me - even more mysterious that some 'Unknown' dependencies can be
> associated with a basic block but not others, despite the code being
> perfectly regular.

I'd need to look at this in more detail in order to answer. I don't use that pass often enough to have an immediate comment.

 -Hal

> 
> Cheers,
> 
> Alex
> 

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