[llvm-dev] restrict func param losing noalias when inlined

[Jeroen Dobbelaere via llvm-dev]

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$