Ryan Taylor via llvm-dev
2020-Sep-29 01:39 UTC
[llvm-dev] restrict func param losing noalias when inlined
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). 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://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200928/8195ea6c/attachment.html>
Johannes Doerfert via llvm-dev
2020-Sep-29 02:33 UTC
[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://llvm.org/docs/LangRef.html#noalias-and-alias-scope-metadata 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://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
Jeroen Dobbelaere via llvm-dev
2020-Sep-29 10:15 UTC
[llvm-dev] restrict func param losing noalias when inlined
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- > 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- > 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- > bin/mailman/listinfo/llvm- > dev__;!!A4F2R9G_pg!OcI4FYow3OO6wwSd0m8OwO1wsKmqilnpEvuIL_magvvs6Jc- > s8_uwsL3GOY0hMHEXq50lObd$
Ryan Taylor via llvm-dev
2020-Sep-29 14:32 UTC
[llvm-dev] Fwd: restrict func param losing noalias when inlined
---------- Forwarded message ---------
From: Ryan Taylor <ryta1203 at gmail.com>
Date: Tue, Sep 29, 2020 at 9:33 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>
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 )
>
> (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/e9e35aca/attachment.html>
Ryan Taylor via llvm-dev
2020-Sep-29 14:33 UTC
[llvm-dev] Fwd: restrict func param losing noalias when inlined
---------- 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>
Johannes Doerfert via llvm-dev
2020-Sep-29 14:38 UTC
[llvm-dev] Fwd: restrict func param losing noalias when inlined
Adding Jeroen and me back to the explicit recipients, also adding Hal, though, see below. On 9/29/20 9:33 AM, Ryan Taylor via llvm-dev wrote:> ---------- 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. :)I'm still unsure what you expect to happen here? The patches are old and, as Jeroen noted, were never merged. There were known problems wrt soundness and completeness, proper restrict support is provided by Jeroen's patch set. ~ Johannes> > 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$ >> > > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev