llvm dev - Sep 2014 - [LLVMdev] noalias and alias.scope metadata producers

Hi all,

In LLVM language reference I read that one can use noalias and alias.scope
metadata to provide more detailed information about pointer aliasing.
However, I was unable to obtain any LLVM IR annotations using this metadata
from any LLVM optimization pass or Clang frontend (am I missing
something?).

If I understand it correctly, this information would complement the
type-based alias information and whatever mechanisms the alias analysis
passes in LLVM compute from the input program. I was wondering if the
coverage provided by these two components is already acceptable or if there
is work that can be done in LLVM IR clients like clang to provide more
information with proper noalias and alias.scope annotations.

Any comments?

Thanks!
Samuel
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20140919/d71621de/attachment.html>

Hi Samuel,

Currently we add this metadata when inlining functions with noalias function
parameters. See the function AddAliasScopeMetadata in
lib/Transforms/Utils/InlineFunction.cpp.

On my TODO list is to generate this metadata directly in Clang for block-level
pointers with restrict, etc. but I've not gotten there yet.

Thanks again,
Hal

----- Original Message -----
> From: "Samuel F Antao" <sfantao at us.ibm.com>
> To: "LLVM Dev" <llvmdev at cs.uiuc.edu>
> Sent: Friday, September 19, 2014 10:42:59 AM
> Subject: [LLVMdev] noalias and alias.scope metadata producers
> 
> 
> 
> 
> Hi all,
> 
> In LLVM language reference I read that one can use noalias and
> alias.scope metadata to provide more detailed information about
> pointer aliasing. However, I was unable to obtain any LLVM IR
> annotations using this metadata from any LLVM optimization pass or
> Clang frontend (am I missing something?).
> 
> If I understand it correctly, this information would complement the
> type-based alias information and whatever mechanisms the alias
> analysis passes in LLVM compute from the input program. I was
> wondering if the coverage provided by these two components is
> already acceptable or if there is work that can be done in LLVM IR
> clients like clang to provide more information with proper noalias
> and alias.scope annotations.
> 
> Any comments?
> 
> Thanks!
> Samuel
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
> 
-- 
Hal Finkel
Assistant Computational Scientist
Leadership Computing Facility
Argonne National Laboratory

Hey Samuel,

I'm not sure if this is interesting for you but maybe it is:

Polly can emit these metadata for loop nests we can analyze. It is based
on runtime alias checks, thus versioning. We are currently fixing the bugs
in the runtime alias check generation we merged yesterday but after that
(or if you like earlier) I can submit the annotation patch for review.
Some limited tests on polybench benchmarks (e.g., 3mm) without any polyhedral
optimizations, thus only parallel and noalias annotations, showed up to
20% improvement.

Best regards,
  Johannes

On 09/19, Samuel F Antao wrote:
> 
> 
> Hi all,
> 
> In LLVM language reference I read that one can use noalias and alias.scope
> metadata to provide more detailed information about pointer aliasing.
> However, I was unable to obtain any LLVM IR annotations using this metadata
> from any LLVM optimization pass or Clang frontend (am I missing
> something?).
> 
> If I understand it correctly, this information would complement the
> type-based alias information and whatever mechanisms the alias analysis
> passes in LLVM compute from the input program. I was wondering if the
> coverage provided by these two components is already acceptable or if there
> is work that can be done in LLVM IR clients like clang to provide more
> information with proper noalias and alias.scope annotations.
> 
> Any comments?
> 
> Thanks!
> Samuel
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

-- 

Johannes Doerfert
Researcher / PhD Student

Compiler Design Lab (Prof. Hack)
Saarland University, Computer Science
Building E1.3, Room 4.26

Tel. +49 (0)681 302-57521 : doerfert at cs.uni-saarland.de
Fax. +49 (0)681 302-3065  : http://www.cdl.uni-saarland.de/people/doerfert
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 213 bytes
Desc: not available
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20140920/b09f1cf8/attachment.sig>

Hal, Johannes,

Thanks for the feedback. I have been digging into this a little bit more
and was able to have some of this metadata being generated. Nevertheless, I
am confused about the semantics of this metadata. Let me explain:

I was expecting the alias metadata to complement the information that alias
analysis passes compute. However, it seems that the alias information of
the pointers used in memory instructions is assumed to be different form
the information of these instructions themselves. Let me give you an
example:

MayAlias: double* %arrayidx.i, double* %arrayidx6
MayAlias:   %4 = load double* %arrayidx.i, align 8, !tbaa !1, !alias.scope
!7, !noalias !10 <->   store double %2, double* %arrayidx6, align 8, !tbaa
!1

becomes:

 MayAlias: double* %arrayidx.i, double* %arrayidx6
NoAlias:   %4 = load double* %arrayidx.i, align 8, !tbaa !1, !alias.scope
!8, !noalias !5 <->   store double %2, double* %arrayidx6, align 8, !tbaa
!1, !alias.scope !5, !noalias !8

after I annotate the store using arrayidx6 as not aliasing with the load
using arrayidx.i. Shouldn't the alias information of the memory
instructions be propagated to the used pointers by the alias analysis pass?
Is this something that was not implemented (if so I'd be happy to work on
this) or is my interpretation of the semantics wrong?

Thanks again!
Samuel


2014-09-19 21:34 GMT-04:00 Johannes Doerfert <doerfert at
cs.uni-saarland.de>:
> Hey Samuel,
>
> I'm not sure if this is interesting for you but maybe it is:
>
> Polly can emit these metadata for loop nests we can analyze. It is based
> on runtime alias checks, thus versioning. We are currently fixing the bugs
> in the runtime alias check generation we merged yesterday but after that
> (or if you like earlier) I can submit the annotation patch for review.
> Some limited tests on polybench benchmarks (e.g., 3mm) without any
> polyhedral
> optimizations, thus only parallel and noalias annotations, showed up to
> 20% improvement.
>
> Best regards,
>   Johannes
>
> On 09/19, Samuel F Antao wrote:
> >
> >
> > Hi all,
> >
> > In LLVM language reference I read that one can use noalias and
> alias.scope
> > metadata to provide more detailed information about pointer aliasing.
> > However, I was unable to obtain any LLVM IR annotations using this
> metadata
> > from any LLVM optimization pass or Clang frontend (am I missing
> > something?).
> >
> > If I understand it correctly, this information would complement the
> > type-based alias information and whatever mechanisms the alias
analysis
> > passes in LLVM compute from the input program. I was wondering if the
> > coverage provided by these two components is already acceptable or if
> there
> > is work that can be done in LLVM IR clients like clang to provide more
> > information with proper noalias and alias.scope annotations.
> >
> > Any comments?
> >
> > Thanks!
> > Samuel
>
> > _______________________________________________
> > LLVM Developers mailing list
> > LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
>
> --
>
> Johannes Doerfert
> Researcher / PhD Student
>
> Compiler Design Lab (Prof. Hack)
> Saarland University, Computer Science
> Building E1.3, Room 4.26
>
> Tel. +49 (0)681 302-57521 : doerfert at cs.uni-saarland.de
> Fax. +49 (0)681 302-3065  : http://www.cdl.uni-saarland.de/people/doerfert
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20140924/6eb29c42/attachment.html>