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

[Ryan Taylor via llvm-dev]

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>