[llvm-dev] Fwd: restrict func param losing noalias when inlined
Ryan Taylor via llvm-dev
llvm-dev at lists.llvm.org
Wed Sep 30 10:34:42 PDT 2020
Yes, I see that, I'm not sure how X86 is getting that info, AA->alias for
these MemoryLocation (s) returns MayAlias when inlined and NoAlias when not
inlined.
Is there some other interface we should be using to get the AA info? (I
would imagine that ModRef would return similar). I was also hoping that
this would fall under ScopedNoAliasAA since it's being inlined, but that
doesn't appear to be the case either, and ScopedNoAliasAA returns MayAlias
if there is no !scope and no !noalias.
Thanks,
Ryan
On Tue, Sep 29, 2020 at 10:40 AM Johannes Doerfert <
johannesdoerfert at gmail.com> wrote:
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200930/df208406/attachment-0001.html>
More information about the llvm-dev
mailing list