[llvm-dev] [RFC] BasicAA considers address spaces?

[Jingyue Wu via llvm-dev]

On Fri, Aug 7, 2015 at 1:00 PM, Daniel Berlin <dberlin at dberlin.org> wrote:

> On Fri, Aug 7, 2015 at 12:45 PM, Matt Arsenault
> <Matthew.Arsenault at amd.com> wrote:
> > On 08/07/2015 12:22 PM, Daniel Berlin via llvm-dev wrote:
> >>
> >> Sorry to be pedantic, but i think it's important to make sure we are
> >> all on the same page that backends can't change the aliasing behavior
> >> of the default address space, only the aliasing behavior of the other
> >> address spaces.
> >
> > Are you saying that we can't say address space 0 doesn't alias other
> address
> > spaces?
>
> No.
> I'm saying "your target can't directly change what address space 0's
> aliasing properties are".
>
> So if you wanted to say "on NVPTX, address space 0 aliases *everything
> in the world, including everything in address space 0*", that is not
> okay.
>
> If they want to say "on NVPTX, all non-default address spaces alias
> everything in address space 0", that is fine.
> (Note: This does end up changing what alias queries return for
> pointers in different address spaces, but it has no effect on two
> pointers solely in address space 0)
>
> In practice, because you can change the properties *of the other
> address spaces*, and mayAlias is a symmetric relationship, it doesn't
> matter for this.
>
> But he wrote " For example,
> >> in CUDA+NVPTX, addrspace(0) aliases everyone."
>
> This is pedantically wrong. CUDA+NVPTX cannot and does not change the
> behavior of aliasing in address space 0, it changes the behavior of
> aliasing in all the other address spaces so that they alias pointers
> in address space 0 :P.
>

Yes. We are on the same page. I was talking about whether two address
spaces alias instead of pointers within the same address space aliasing.


>
> (As i said, it's really pedantic, but we need to be absolutely clear
> that targets do not control the properties of address space 0)
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150807/09cee71d/attachment.html>