<div dir="ltr">Hal, Johannes,<div><br></div><div>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:</div><div><br></div><div>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:</div><div><br></div><div><div>MayAlias:<span class="" style="white-space:pre"> </span>double* %arrayidx.i, double* %arrayidx6</div><div>MayAlias:   %4 = load double* %arrayidx.i, align 8, !tbaa !1, !alias.scope !7, !noalias !10 <->   store double %2, double* %arrayidx6, align 8, !tbaa !1</div></div><div><br></div><div>becomes:</div><div><br></div><div><div> MayAlias:<span class="" style="white-space:pre">  </span>double* %arrayidx.i, double* %arrayidx6</div><div>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</div></div><div><br></div><div>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?</div><div><br></div><div>Thanks again!</div><div>Samuel</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">2014-09-19 21:34 GMT-04:00 Johannes Doerfert <span dir="ltr"><<a href="mailto:doerfert@cs.uni-saarland.de" target="_blank">doerfert@cs.uni-saarland.de</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hey Samuel,<br>
<br>
I'm not sure if this is interesting for you but maybe it is:<br>
<br>
Polly can emit these metadata for loop nests we can analyze. It is based<br>
on runtime alias checks, thus versioning. We are currently fixing the bugs<br>
in the runtime alias check generation we merged yesterday but after that<br>
(or if you like earlier) I can submit the annotation patch for review.<br>
Some limited tests on polybench benchmarks (e.g., 3mm) without any polyhedral<br>
optimizations, thus only parallel and noalias annotations, showed up to<br>
20% improvement.<br>
<br>
Best regards,<br>
  Johannes<br>
<div><div class="h5"><br>
On 09/19, Samuel F Antao wrote:<br>
><br>
><br>
> Hi all,<br>
><br>
> In LLVM language reference I read that one can use noalias and alias.scope<br>
> metadata to provide more detailed information about pointer aliasing.<br>
> However, I was unable to obtain any LLVM IR annotations using this metadata<br>
> from any LLVM optimization pass or Clang frontend (am I missing<br>
> something?).<br>
><br>
> If I understand it correctly, this information would complement the<br>
> type-based alias information and whatever mechanisms the alias analysis<br>
> passes in LLVM compute from the input program. I was wondering if the<br>
> coverage provided by these two components is already acceptable or if there<br>
> is work that can be done in LLVM IR clients like clang to provide more<br>
> information with proper noalias and alias.scope annotations.<br>
><br>
> Any comments?<br>
><br>
> Thanks!<br>
> Samuel<br>
<br>
</div></div><span class="">> _______________________________________________<br>
> LLVM Developers mailing list<br>
> <a href="mailto:LLVMdev@cs.uiuc.edu">LLVMdev@cs.uiuc.edu</a>         <a href="http://llvm.cs.uiuc.edu" target="_blank">http://llvm.cs.uiuc.edu</a><br>
> <a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a><br>
<br>
<br>
--<br>
<br>
</span>Johannes Doerfert<br>
Researcher / PhD Student<br>
<br>
Compiler Design Lab (Prof. Hack)<br>
Saarland University, Computer Science<br>
Building E1.3, Room 4.26<br>
<br>
Tel. <a href="tel:%2B49%20%280%29681%20302-57521" value="+4968130257521">+49 (0)681 302-57521</a> : <a href="mailto:doerfert@cs.uni-saarland.de">doerfert@cs.uni-saarland.de</a><br>
Fax. <a href="tel:%2B49%20%280%29681%20302-3065" value="+496813023065">+49 (0)681 302-3065</a>  : <a href="http://www.cdl.uni-saarland.de/people/doerfert" target="_blank">http://www.cdl.uni-saarland.de/people/doerfert</a><br>
<br>_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:LLVMdev@cs.uiuc.edu">LLVMdev@cs.uiuc.edu</a>         <a href="http://llvm.cs.uiuc.edu" target="_blank">http://llvm.cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a><br>
<br></blockquote></div><br></div>