<div class="socmaildefaultfont" dir="ltr" style="font-family:Arial, Helvetica, sans-serif;font-size:10pt" ><div dir="ltr" >Hi Johannes,</div>
<div dir="ltr" > </div>
<div dir="ltr" >Thanks for the info. It sounds interesting. At this point, I am not sure if it helps or not. Could you provide more information? E.g. motivating examples, rationale etc. For the list after the llvm.assume call, does it allow a list of more than two items? How about if I have many calls, does it affect compile time?</div>
<div dir="ltr" ><br>Kelvin</div>
<div dir="ltr" > </div>
<div dir="ltr" > </div>
<blockquote data-history-content-modified="1" dir="ltr" style="border-left:solid #aaaaaa 2px; margin-left:5px; padding-left:5px; direction:ltr; margin-right:0px" >----- Original message -----<br>From: Johannes Doerfert <johannesdoerfert@gmail.com><br>To: Kelvin Li <kli@ca.ibm.com>, llvm-dev@lists.llvm.org, flang-dev@lists.llvm.org<br>Cc:<br>Subject: [EXTERNAL] Re: [llvm-dev] Represent Fortran alias information in LLVM IR<br>Date: Wed, May 6, 2020 11:05 AM<br> <br><!--Notes ACF
<meta http-equiv="Content-Type" content="text/html; charset=utf8" >-->
<p><font face="Hack Nerd Font Mono" >Hi Kelvin,</font></p>
<p> </p>
<p><font face="Hack Nerd Font Mono" >recently it came up twice that we might want to have alias information looking something like this:</font></p>
<p><font face="Hack Nerd Font Mono" >`llvm.assume(i1 true) ['noalias'(%ptrA, %ptrB)]`</font></p>
<p><font face="Hack Nerd Font Mono" >Which is supposed to mean that under the control condition of the `llvm.assume`,</font></p>
<p><font face="Hack Nerd Font Mono" >anything derived from `%ptrA` will not alias anything derived from `%ptrB`.</font></p>
<p><font face="Hack Nerd Font Mono" >We will have a separate RFC for this but I was wondering if it might benefit your use case.</font></p>
<p> </p>
<p><font face="Hack Nerd Font Mono" >Let me know if you need more information :)</font></p>
<p> </p>
<p><font face="Hack Nerd Font Mono" >Looking forward to your thoughts!</font></p>
<p> </p>
<p><font face="Hack Nerd Font Mono" >Cheers,</font></p>
<p><font face="Hack Nerd Font Mono" > Johannes</font></p>
<p> </p>
<div>On 4/14/20 1:21 PM, Kelvin Li via llvm-dev wrote:</div>
<blockquote cite="mid:OF61357B01.99800180-ON8525854A.0052153B-8525854A.0064CD05@notes.na.collabserv.com" type="cite" ><div><font size="2" face="Default Monospace,Courier New,Courier,monospace" >Hi,<br><br>We, IBM XL Fortran compiler team, is interested in representing Fortran<br>alias information in LLVM IR. We use the XL Fortran frontend to emit LLVM<br>IR that includes alias information to feed to the LLVM in order to create<br>object files. For the Fortran alias representation in LLVM IR, we<br>considered both TBAA and ScopeAlias/NoAlias metadata approaches, we think<br>that the ScopeAlias/NoAlias metadata is more appropriate for refined alias<br>information for Fortran. The XL Fortran frontend emits the alias info in<br>terms of what other symbols that a symbol alias to. We experiment a<br>scheme that represents the alias relation in terms of noalias and scope<br>alias metadata in LLVM IR. An example is shown in the attached slides and<br>the full .ll file for the example is also attached.<br><br>In this experiment, we observe that the performance gain varies from<br>workload to workload, and the extent can be from a few percent to 2X. The<br>compile time and the size of the IR increase as well.<br><br>We briefly investigated the possible causes of the long compile time and<br>the large IR size issues. For the compile-time performance, we observe:<br>- Each alias query (ScopedNoAliasAAResult::mayAliasInScopes) involves<br>partitioning a metadata set based on the domains of the metadata elements.<br> One possible solution is that pre-partitioning the metadata sets and<br>maintaining the partitions on updates can help.<br>- Intersection of noalias sets is O(n^2) as metadata elements do not have<br>any ordering. Defining some order on the elements can help significantly.<br>- Some optimizations do not scale well when the size of the working<br>instruction set increases, e.g. SCEV functions.<br><br>For the size of LLVM IR, the noalias metadata requires a flattened set of<br>metadata nodes. A hierarchical representation can reduce memory<br>footprint.<br><br>With these findings, we would like to start a thread to discuss how to<br>express Fortran alias in LLVM IR. Any comments and information regarding<br>any previous approaches are welcome.<br><br><br><br><br><br>Thanks,<br>Kelvin Li<br>Tarique Islam</font><br><br><br><br><br><br> </div>
<fieldset> </fieldset>
<div><font size="2" face="Default Monospace,Courier New,Courier,monospace" >_______________________________________________<br>LLVM Developers mailing list<br><a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br><a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a></font></div></blockquote></blockquote>
<div dir="ltr" > </div></div><BR>