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

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? In this case we really need to fix LLVM's concept of 
default address space because this is highly problematic for us. We're 
constrained to use it in some cases because we can't alloca in a 
different address space, but ideally if we have problems like this we 
wouldn't ever use address space 0.

-Matt

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.

(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)

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>