<div dir="ltr"><div class="gmail_default" style="font-family:verdana,sans-serif">Hal, a couple of questions:</div><div class="gmail_default" style="font-family:verdana,sans-serif"><br></div><div class="gmail_default" style="font-family:verdana,sans-serif">1. Do you preserve alias to stores+loads derived through a different @llvm.noalias call which has <u>different</u> scope metadata? Couldn't that be treated similarly to S+Ls derived from other identified objects? </div><div class="gmail_default" style="font-family:verdana,sans-serif"><br></div><div class="gmail_default" style="font-family:verdana,sans-serif">2. Can you describe the case for explicitly preventing the intrinsic being hoisted out of a loop? Since the intrinsic generates a new pointer, wouldn't the interesting cases be handled by avoiding commoning of the intrinsic?</div><div class="gmail_default" style="font-family:verdana,sans-serif"><br></div></div><div class="gmail_extra"><br clear="all"><div><div class="gmail_signature"><div dir="ltr"><div><div style="line-height:1.5em;padding-top:10px;margin-top:10px;font-family:sans-serif;font-size:small"><span style="color:rgb(85,85,85);border-width:2px 0px 0px;border-style:solid;border-color:rgb(213,15,37);padding-top:2px;margin-top:2px">Raúl E Silvera |</span><span style="color:rgb(85,85,85);border-width:2px 0px 0px;border-style:solid;border-color:rgb(51,105,232);padding-top:2px;margin-top:2px"> SWE |</span><span style="color:rgb(85,85,85);border-width:2px 0px 0px;border-style:solid;border-color:rgb(0,153,57);padding-top:2px;margin-top:2px"> <a href="mailto:rsilvera@google.com" target="_blank">rsilvera@google.com</a> |</span><span style="border-width:2px 0px 0px;border-style:solid;border-color:rgb(238,178,17);padding-top:2px;margin-top:2px"><font color="#555555"> </font><font color="#0033bb"><u>408-789-2846</u></font></span></div><br></div></div></div></div>
<br><div class="gmail_quote">On Thu, Nov 13, 2014 at 7:23 PM, Hal Finkel <span dir="ltr"><<a href="mailto:hfinkel@anl.gov" target="_blank">hfinkel@anl.gov</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">----- Original Message -----<br>
> From: "Chandler Carruth" <<a href="mailto:chandlerc@google.com">chandlerc@google.com</a>><br>
> To: "Hal Finkel" <<a href="mailto:hfinkel@anl.gov">hfinkel@anl.gov</a>><br>
> Cc: "LLVM Developers Mailing List" <<a href="mailto:llvmdev@cs.uiuc.edu">llvmdev@cs.uiuc.edu</a>><br>
> Sent: Thursday, November 13, 2014 7:02:58 PM<br>
> Subject: Re: [LLVMdev] Upcoming Changes/Additions to Scoped-NoAlias metadata<br>
><br>
><br>
><br>
><br>
><br>
> On Thu, Nov 13, 2014 at 4:44 PM, Hal Finkel < <a href="mailto:hfinkel@anl.gov">hfinkel@anl.gov</a> ><br>
> wrote:<br>
><br>
><br>
> After discussing this with Chandler offline last week, here's the<br>
> proposed solution: instead of having both !alias.scope and !noalias<br>
> metadata, we'll have only !alias.scope metadata and an intrinsic:<br>
> i8* @llvm.noalias(i8* ptr, !metadata !?) where the metadata argument<br>
> corresponds to a list of !alias.scopes. The idea being that the<br>
> pointer returned by this intrinsic, and all pointers derived from<br>
> it, are assumed not to alias with memory accesses tagged with any of<br>
> the associated !alias.scope metadata entries.<br>
><br>
><br>
> Could you give examples? I don't quite follow this. I had thought<br>
> that the analysis would be slightly different. My expectation is<br>
> that each noalias argument pointer would turn into a @llvm.noalias<br>
> call, all of them sharing a single metadata "scope". And then any<br>
> loads or stores through a pointer derived from a @llvm.noalias call<br>
> would never alias loads and stores derived through a different<br>
> @llvm.noalias call which had the same scope metadata.<br>
<br>
</span>Sorry, I did not state this very well. Yes, that's correct, with the exception that "derived through a different<br>
> @llvm.noalias call which had the same scope metadata" should also be supplemented with being derived from other identified objects (just like with a noalias argument attribute).<br>
<span class=""><br>
><br>
><br>
> This intrinsic needs to carry control dependencies (it cannot be<br>
> hoisted out of a loop, for example) -- in this sense it is very much<br>
> like @llvm.assume. And like @llvm.assume, we'll need to add logic to<br>
> various passes to ignore it as appropriate so that it does not block<br>
> optimizations unnecessarily.<br>
<br>
> We should do something to make this simpler. I think we should have<br>
> an intrinsic inst base class that assume, lifetime, and other<br>
> intrinsics which do not represent actual code in the final program<br>
> derive from so that we don't have to update these lists all over the<br>
> place. If we need 2 tiers to model assume & noalias as distinct from<br>
> the lifetime or other intrinsics, fine. We should have high-level<br>
> categories that can be tested and updated.<br>
<br>
</span>Agreed. There is come commonality here that can be exploited for at least some of the passes.<br>
<span class="HOEnZb"><font color="#888888"><br>
 -Hal<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
<br>
--<br>
Hal Finkel<br>
Assistant Computational Scientist<br>
Leadership Computing Facility<br>
Argonne National Laboratory<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>
</div></div></blockquote></div><br></div>