[llvm-dev] Fwd: restrict func param losing noalias when inlined
Ryan Taylor via llvm-dev
llvm-dev at lists.llvm.org
Tue Sep 29 07:33:17 PDT 2020
---------- Forwarded message ---------
From: Ryan Taylor <ryta1203 at gmail.com>
Date: Tue, Sep 29, 2020 at 10:29 AM
Subject: Re: [llvm-dev] restrict func param losing noalias when inlined
To: Jeroen Dobbelaere <Jeroen.Dobbelaere at synopsys.com>
Cc: Johannes Doerfert <johannesdoerfert at gmail.com>
Ok, maybe Hal will find the time to chime in. :)
On Tue, Sep 29, 2020 at 9:50 AM Jeroen Dobbelaere <
Jeroen.Dobbelaere at synopsys.com> wrote:
> This is clearly using Hal Finkel's local restrict changes. According to
> the rules that Hal Finkel used, the load and the store should not alias..
>
>
>
> Not sure why you would get other results, but then again, that code
> consists of a number of patches and you might be triggering one of the
>
> cases that don't work.
>
>
>
> Greetings,
>
>
>
> Jeroen
>
>
>
>
>
>
>
> *From:* Ryan Taylor <ryta1203 at gmail.com>
> *Sent:* Tuesday, September 29, 2020 15:33
> *To:* Jeroen Dobbelaere <dobbel at synopsys.com>
> *Cc:* Johannes Doerfert <johannesdoerfert at gmail.com>
> *Subject:* Re: [llvm-dev] restrict func param losing noalias when inlined
>
>
>
> Sorry, I didn't have the IR on the computer I was emailing from earlier.
>
>
>
> @aa = global [1000 x float] zeroinitializer, section ".dram0.data", align
> 32
> @pa = local_unnamed_addr global float* getelementptr inbounds ([1000 x
> float], [1000 x float]* @aa, i32 0, i32 0), align 4
> @bb = global [1000 x float] zeroinitializer, section ".dram0.data", align
> 32
> @pb = local_unnamed_addr global float* getelementptr inbounds ([1000 x
> float], [1000 x float]* @bb, i32 0, i32 0), align 4
>
> ; Function Attrs: noinline nounwind
> define i32 @main() local_unnamed_addr #0 !dbg !6 {
> entry:
> %0 = load float*, float** @pa, align 4, !dbg !8, !tbaa !9
> %1 = load float*, float** @pb, align 4, !dbg !13, !tbaa !9
> *%2 = tail call float* @llvm.noalias.p0f32(float* %0, metadata !14),
> !dbg !17*
> br label %vector.body, !dbg !18
>
> vector.body: ; preds = %vector.body,
> %entry
> %index = phi i32 [ 0, %entry ], [ %index.next, %vector.body ], !dbg !21
> %3 = getelementptr inbounds float, float* %1, i32 %index, !dbg !22
> %4 = bitcast float* %3 to <8 x float>*, !dbg !22
> %wide.load = load <8 x float>, <8 x float>* %4, align 4, !dbg !22, !tbaa
> !23, *!noalias !14*
> %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
> %6 = getelementptr inbounds float, float* %2, i32 %index, !dbg !26
> %7 = bitcast float* %6 to <8 x float>*, !dbg !27
> store <8 x float> %5, <8 x float>* %7, align 4, !dbg !27, !tbaa !23, *!noalias
> !14*
> %index.next = add i32 %index, 8, !dbg !21
> %8 = icmp eq i32 %index.next, 1000, !dbg !21
> br i1 %8, label %func.exit, label %vector.body, !dbg !18, !llvm.loop !28
>
> func.exit: ; preds = %vector.body
> ret i32 0, !dbg !32
> }
>
>
>
> On Tue, Sep 29, 2020 at 9:23 AM Jeroen Dobbelaere <
> Jeroen.Dobbelaere at synopsys.com> wrote:
>
> Hi Ryan,
>
>
>
> According to the code, it should be safe to assume noalias. plain clang-6
> and clang-trunk do this. (See https://www.godbolt.org/z/7sE3MP
> <https://urldefense.com/v3/__https:/www.godbolt.org/z/7sE3MP__;!!A4F2R9G_pg!M3KIv3WODN4vGwQmrZQZvsRic33cs_Gw5dbnnQSufR-6E-bithz19GTd0rt9Vc9WQfS2iuB_$>
> )
>
> (at least, they vectorize when 'restrict' exists)
>
>
>
> 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
>
>
>
> (aka, try adding '-emit-llvm' to the godbolt example)
>
>
>
> Greetings,
>
>
>
> Jeroen
>
>
>
>
>
>
>
> *From:* Ryan Taylor <ryta1203 at gmail.com>
> *Sent:* Tuesday, September 29, 2020 15:02
> *To:* Jeroen Dobbelaere <dobbel at synopsys.com>
> *Cc:* Johannes Doerfert <johannesdoerfert at gmail.com>
> *Subject:* Re: [llvm-dev] restrict func param losing noalias when inlined
>
>
>
> Jeroen,
>
>
>
> 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.
>
>
>
> Interestingly enough, "capture" works fine (no inline).
>
>
>
> Thanks,
>
>
>
> Ryan
>
>
>
> On Tue, Sep 29, 2020 at 4:09 AM Jeroen Dobbelaere <
> Jeroen.Dobbelaere at synopsys.com> wrote:
>
> As far as I know, the 'llvm.noalias' intrinsic has never been part of the
> main llvm.
>
> So, you might have applied some of Hal Finkel's patches that introduced
> them
> in an attempt to fix some of the issues with inlining and noalias ?
>
> In that case, the '!alias.scope' is indeed not needed, and the
> 'llvm.noalias' intrinsic is used to
> deduce the 'based on' relationship of a restrict pointer. But those
> patches have a number
> of known issues. The more complete approach (aka 'full restrict support')
> which is under review now
> fixes those issues... but that's on top-of-tree, not on llvm-6.
>
> Greetings,
>
> Jeroen Dobbelaere
>
>
>
>
> > -----Original Message-----
> > From: llvm-dev <llvm-dev-bounces at lists.llvm.org> On Behalf Of Johannes
> > Doerfert via llvm-dev
> > Sent: Tuesday, September 29, 2020 04:33
> > To: Ryan Taylor <ryta1203 at gmail.com>
> > Cc: llvm-dev <llvm-dev at lists.llvm.org>
> > Subject: Re: [llvm-dev] restrict func param losing noalias when inlined
> >
> >
> > On 9/28/20 8:39 PM, Ryan Taylor wrote:
> > > Johannes,
> > >
> > > Thanks, I have been following along some of the thread(s) and the phab
> > > reviews. The scope of this work is more encompassing than our current
> needs
> > > and I've looked at trying to carve a piece out.
> > >
> > > It's not clear to me what purpose the llvm.noalias intrinsic serves
> right
> > > now. Also, if a mem instruction has !noalias metadata, then it should
> not
> > > be aliased, but I must be missing some complexity. For example, if you
> look
> > > at the alias of two memory locations and they are both tagged with
> noalias
> > > MD, that should be safe to NoAlias providing they have no specific
> !scope
> > > tag? I've looked at the ScopedNoAliasAA but during the inline no
> !scope MD
> > > is created therefore it's not marked as NoAlias from that analysis (it
> > > returns MayAlias if no scope MD or no noalias MD).
> >
> > `!noalias` metadata needs a scope to be useful, otherwise it is not:
> >
> >
> https://urldefense.com/v3/__https://llvm.org/docs/LangRef.html*noalias-and-
> <https://urldefense.com/v3/__https:/llvm.org/docs/LangRef.html*noalias-and->
> > alias-scope-
> >
> metadata__;Iw!!A4F2R9G_pg!OcI4FYow3OO6wwSd0m8OwO1wsKmqilnpEvuIL_magvvs6Jc-
> > s8_uwsL3GOY0hMHEXpWpxUaJ$
> >
> > Though I don't know what the implementation status in 6.0 was.
> >
> > ~ Johannes
> >
> >
> > > Thanks,
> > >
> > > Ryan
> > >
> > > On Mon, Sep 28, 2020, 8:53 PM Johannes Doerfert <
> johannesdoerfert at gmail.com>
> > > wrote:
> > >
> > >> Hi Ryan,
> > >>
> > >> the alias metadata was (and is) broken for various reasons.
> > >> he replacement is currently under review, I can point you to it,
> > >> however, to be honest, I'm unclear how we are supposed to help
> > >> you with LLVM 6 right now.
> > >>
> > >> Cheers,
> > >> Johannes
> > >>
> > >>
> > >> On 9/28/20 7:00 PM, Ryan Taylor via llvm-dev wrote:
> > >>> Given some code:
> > >>>
> > >>> void func (float * restrict a, float *b) {
> > >>> for (int i =0; i < 100; ++i) {
> > >>> a[i] = b[i] + 1;
> > >>> }
> > >>> }
> > >>>
> > >>> float * aa;
> > >>> float * bb;
> > >>> int main() {
> > >>> func(aa, bb);
> > >>> return 0;
> > >>> }
> > >>>
> > >>> produces IR that has the llvm.noalias intrinsic along with the
> !noalias
> > >>> metadata:for both the load and store, however, AA returns MayAlias, I
> > >> would
> > >>> expect a NoAlias?
> > >>>
> > >>> This is also an older version of llvm: 6 (yes, I know, sigh).
> > >>>
> > >>> Thanks,
> > >>>
> > >>> Ryan
> > >>>
> > >>>
> > >>> _______________________________________________
> > >>> LLVM Developers mailing list
> > >>> llvm-dev at lists.llvm.org
> > >>> https://urldefense.com/v3/__https://lists.llvm.org/cgi-
> <https://urldefense.com/v3/__https:/lists.llvm.org/cgi->
> > bin/mailman/listinfo/llvm-
> > dev__;!!A4F2R9G_pg!OcI4FYow3OO6wwSd0m8OwO1wsKmqilnpEvuIL_magvvs6Jc-
> > s8_uwsL3GOY0hMHEXq50lObd$
> > _______________________________________________
> > LLVM Developers mailing list
> > llvm-dev at lists.llvm.org
> > https://urldefense.com/v3/__https://lists.llvm.org/cgi-
> <https://urldefense.com/v3/__https:/lists.llvm.org/cgi->
> > bin/mailman/listinfo/llvm-
> > dev__;!!A4F2R9G_pg!OcI4FYow3OO6wwSd0m8OwO1wsKmqilnpEvuIL_magvvs6Jc-
> > s8_uwsL3GOY0hMHEXq50lObd$
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200929/cfe81a47/attachment.html>
More information about the llvm-dev
mailing list