<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">---------- Forwarded message ---------<br>From: <strong class="gmail_sendername" dir="auto">Ryan Taylor</strong> <span dir="auto"><<a href="mailto:ryta1203@gmail.com">ryta1203@gmail.com</a>></span><br>Date: Tue, Sep 29, 2020 at 9:33 AM<br>Subject: Re: [llvm-dev] restrict func param losing noalias when inlined<br>To: Jeroen Dobbelaere <<a href="mailto:Jeroen.Dobbelaere@synopsys.com">Jeroen.Dobbelaere@synopsys.com</a>><br>Cc: Johannes Doerfert <<a href="mailto:johannesdoerfert@gmail.com">johannesdoerfert@gmail.com</a>><br></div><br><br><div dir="ltr">Sorry, I didn't have the IR on the computer I was emailing from earlier.<div><br></div><div>@aa = global [1000 x float] zeroinitializer, section ".dram0.data", align 32<br>@pa = local_unnamed_addr global float* getelementptr inbounds ([1000 x float], [1000 x float]* @aa, i32 0, i32 0), align 4<br>@bb = global [1000 x float] zeroinitializer, section ".dram0.data", align 32<br>@pb = local_unnamed_addr global float* getelementptr inbounds ([1000 x float], [1000 x float]* @bb, i32 0, i32 0), align 4<br><br>; Function Attrs: noinline nounwind<br>define i32 @main() local_unnamed_addr #0 !dbg !6 {<br>entry:<br> %0 = load float*, float** @pa, align 4, !dbg !8, !tbaa !9<br> %1 = load float*, float** @pb, align 4, !dbg !13, !tbaa !9<br> <b>%2 = tail call float* @llvm.noalias.p0f32(float* %0, metadata !14), !dbg !17</b><br> br label %vector.body, !dbg !18<br><br>vector.body: ; preds = %vector.body, %entry<br> %index = phi i32 [ 0, %entry ], [ %index.next, %vector.body ], !dbg !21<br> %3 = getelementptr inbounds float, float* %1, i32 %index, !dbg !22<br> %4 = bitcast float* %3 to <8 x float>*, !dbg !22<br> %wide.load = load <8 x float>, <8 x float>* %4, align 4, !dbg !22, !tbaa !23, <b>!noalias !14</b><br> %5 = fadd reassoc nnan nsz contract <8 x float> %wide.load, <float 1.000000e+00, float 1.000000e+00, float 1.000000e+00, float 1.000000e+00, float 1.000000e+00, float 1.000000e+00, float 1.000000e+00, float 1.000000e+00>, !dbg !25<br> %6 = getelementptr inbounds float, float* %2, i32 %index, !dbg !26<br> %7 = bitcast float* %6 to <8 x float>*, !dbg !27<br> store <8 x float> %5, <8 x float>* %7, align 4, !dbg !27, !tbaa !23, <b>!noalias !14</b><br> %index.next = add i32 %index, 8, !dbg !21<br> %8 = icmp eq i32 %index.next, 1000, !dbg !21<br> br i1 %8, label %func.exit, label %vector.body, !dbg !18, !llvm.loop !28<br><br>func.exit: ; preds = %vector.body<br> ret i32 0, !dbg !32<br>}</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Sep 29, 2020 at 9:23 AM Jeroen Dobbelaere <<a href="mailto:Jeroen.Dobbelaere@synopsys.com" target="_blank">Jeroen.Dobbelaere@synopsys.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div lang="EN-US">
<div>
<p class="MsoNormal">Hi Ryan,<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">According to the code, it should be safe to assume noalias. plain clang-6 and clang-trunk do this. (See
<a href="https://www.godbolt.org/z/7sE3MP" target="_blank">https://www.godbolt.org/z/7sE3MP</a> )<u></u><u></u></p>
<p class="MsoNormal">(at least, they vectorize when 'restrict' exists)<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">You did not provide your llvm-ir, so I cannot conclude anything about your case. But, as you mentioned seeing a llvm.noalias intrinsics, you are not using plain clang-6<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">(aka, try adding '-emit-llvm' to the godbolt example)<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">Greetings,<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">Jeroen<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<div>
<div style="border-right:none;border-bottom:none;border-left:none;border-top:1pt solid rgb(225,225,225);padding:3pt 0cm 0cm">
<p class="MsoNormal"><b>From:</b> Ryan Taylor <<a href="mailto:ryta1203@gmail.com" target="_blank">ryta1203@gmail.com</a>> <br>
<b>Sent:</b> Tuesday, September 29, 2020 15:02<br>
<b>To:</b> Jeroen Dobbelaere <<a href="mailto:dobbel@synopsys.com" target="_blank">dobbel@synopsys.com</a>><br>
<b>Cc:</b> Johannes Doerfert <<a href="mailto:johannesdoerfert@gmail.com" target="_blank">johannesdoerfert@gmail.com</a>><br>
<b>Subject:</b> Re: [llvm-dev] restrict func param losing noalias when inlined<u></u><u></u></p>
</div>
</div>
<p class="MsoNormal"><u></u> <u></u></p>
<div>
<p class="MsoNormal">Jeroen,<u></u><u></u></p>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal"> So it is, or is not, safe to assume no aliasing given the noalias metadata? In my example, it is clearly safe, yet I have to assume there is a reason that addresses with the noalias aren't included in the AA as NoAlias.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal"> Interestingly enough, "capture" works fine (no inline).<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">Thanks,<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">Ryan<u></u><u></u></p>
</div>
</div>
<p class="MsoNormal"><u></u> <u></u></p>
<div>
<p class="MsoNormal">On Tue, Sep 29, 2020 at 4:09 AM Jeroen Dobbelaere <<a href="mailto:Jeroen.Dobbelaere@synopsys.com" target="_blank">Jeroen.Dobbelaere@synopsys.com</a>> wrote:<u></u><u></u></p>
</div>
<p class="MsoNormal">As far as I know, the 'llvm.noalias' intrinsic has never been part of the main llvm.<br>
<br>
So, you might have applied some of Hal Finkel's patches that introduced them<br>
in an attempt to fix some of the issues with inlining and noalias ?<br>
<br>
In that case, the '!alias.scope' is indeed not needed, and the 'llvm.noalias' intrinsic is used to<br>
deduce the 'based on' relationship of a restrict pointer. But those patches have a number<br>
of known issues. The more complete approach (aka 'full restrict support') which is under review now<br>
fixes those issues... but that's on top-of-tree, not on llvm-6.<br>
<br>
Greetings,<br>
<br>
Jeroen Dobbelaere<br>
<br>
<br>
<br>
<br>
> -----Original Message-----<br>
> From: llvm-dev <<a href="mailto:llvm-dev-bounces@lists.llvm.org" target="_blank">llvm-dev-bounces@lists.llvm.org</a>> On Behalf Of Johannes<br>
> Doerfert via llvm-dev<br>
> Sent: Tuesday, September 29, 2020 04:33<br>
> To: Ryan Taylor <<a href="mailto:ryta1203@gmail.com" target="_blank">ryta1203@gmail.com</a>><br>
> Cc: llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>><br>
> Subject: Re: [llvm-dev] restrict func param losing noalias when inlined<br>
> <br>
> <br>
> On 9/28/20 8:39 PM, Ryan Taylor wrote:<br>
> > Johannes,<br>
> ><br>
> > Thanks, I have been following along some of the thread(s) and the phab<br>
> > reviews. The scope of this work is more encompassing than our current needs<br>
> > and I've looked at trying to carve a piece out.<br>
> ><br>
> > It's not clear to me what purpose the llvm.noalias intrinsic serves right<br>
> > now. Also, if a mem instruction has !noalias metadata, then it should not<br>
> > be aliased, but I must be missing some complexity. For example, if you look<br>
> > at the alias of two memory locations and they are both tagged with noalias<br>
> > MD, that should be safe to NoAlias providing they have no specific !scope<br>
> > tag? I've looked at the ScopedNoAliasAA but during the inline no !scope MD<br>
> > is created therefore it's not marked as NoAlias from that analysis (it<br>
> > returns MayAlias if no scope MD or no noalias MD).<br>
> <br>
> `!noalias` metadata needs a scope to be useful, otherwise it is not:<br>
> <br>
> <a href="https://urldefense.com/v3/__https:/llvm.org/docs/LangRef.html*noalias-and-" target="_blank">
https://urldefense.com/v3/__https://llvm.org/docs/LangRef.html*noalias-and-</a><br>
> alias-scope-<br>
> metadata__;Iw!!A4F2R9G_pg!OcI4FYow3OO6wwSd0m8OwO1wsKmqilnpEvuIL_magvvs6Jc-<br>
> s8_uwsL3GOY0hMHEXpWpxUaJ$<br>
> <br>
> Though I don't know what the implementation status in 6.0 was.<br>
> <br>
> ~ Johannes<br>
> <br>
> <br>
> > Thanks,<br>
> ><br>
> > Ryan<br>
> ><br>
> > On Mon, Sep 28, 2020, 8:53 PM Johannes Doerfert <<a href="mailto:johannesdoerfert@gmail.com" target="_blank">johannesdoerfert@gmail.com</a>><br>
> > wrote:<br>
> ><br>
> >> Hi Ryan,<br>
> >><br>
> >> the alias metadata was (and is) broken for various reasons.<br>
> >> he replacement is currently under review, I can point you to it,<br>
> >> however, to be honest, I'm unclear how we are supposed to help<br>
> >> you with LLVM 6 right now.<br>
> >><br>
> >> Cheers,<br>
> >> Johannes<br>
> >><br>
> >><br>
> >> On 9/28/20 7:00 PM, Ryan Taylor via llvm-dev wrote:<br>
> >>> Given some code:<br>
> >>><br>
> >>> void func (float * restrict a, float *b) {<br>
> >>> for (int i =0; i < 100; ++i) {<br>
> >>> a[i] = b[i] + 1;<br>
> >>> }<br>
> >>> }<br>
> >>><br>
> >>> float * aa;<br>
> >>> float * bb;<br>
> >>> int main() {<br>
> >>> func(aa, bb);<br>
> >>> return 0;<br>
> >>> }<br>
> >>><br>
> >>> produces IR that has the llvm.noalias intrinsic along with the !noalias<br>
> >>> metadata:for both the load and store, however, AA returns MayAlias, I<br>
> >> would<br>
> >>> expect a NoAlias?<br>
> >>><br>
> >>> This is also an older version of llvm: 6 (yes, I know, sigh).<br>
> >>><br>
> >>> Thanks,<br>
> >>><br>
> >>> Ryan<br>
> >>><br>
> >>><br>
> >>> _______________________________________________<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://urldefense.com/v3/__https:/lists.llvm.org/cgi-" target="_blank">
https://urldefense.com/v3/__https://lists.llvm.org/cgi-</a><br>
> bin/mailman/listinfo/llvm-<br>
> dev__;!!A4F2R9G_pg!OcI4FYow3OO6wwSd0m8OwO1wsKmqilnpEvuIL_magvvs6Jc-<br>
> s8_uwsL3GOY0hMHEXq50lObd$<br>
> _______________________________________________<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://urldefense.com/v3/__https:/lists.llvm.org/cgi-" target="_blank">
https://urldefense.com/v3/__https://lists.llvm.org/cgi-</a><br>
> bin/mailman/listinfo/llvm-<br>
> dev__;!!A4F2R9G_pg!OcI4FYow3OO6wwSd0m8OwO1wsKmqilnpEvuIL_magvvs6Jc-<br>
> s8_uwsL3GOY0hMHEXq50lObd$<u></u><u></u></p>
</div>
</div>
</blockquote></div>
</div></div>