llvm dev - Aug 2019 - [RFC] Changing X86 data layout for address spaces

I really hate to dip my toe in here, because it will only reveal my total
ignorance, but….

Do the "usual rules around addrspacecast" say when different address
spaces can alias?  I remember somebody using address spaces to represent
something like special off-to-the-side device memory, which obviously could
never alias main memory, whereas other uses like the 32/64-bit thing will
certainly have the 32-bit space aliasing (likely disjoint parts of) the 64-bit
space, and the exact mapping of 32-to-64 might vary across OSes.
--paulr

From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On Behalf Of Reid
Kleckner via llvm-dev
Sent: Wednesday, July 31, 2019 1:44 PM
To: Philip Reames
Cc: llvm-dev; John Reagan
Subject: Re: [llvm-dev] [RFC] Changing X86 data layout for address spaces

On Wed, Jul 31, 2019 at 10:29 AM Philip Reames via llvm-dev <llvm-dev at
lists.llvm.org<mailto:llvm-dev at lists.llvm.org>> wrote:

Looks like I made my point in an accidentally really confusing way.  Let me try
again w/Matt's correction in mind.

I want to make sure that the middle end optimizer code is *driven by the data
layout*.  I am not trying to express an opinion on how that data layout is
populated (frontend, backedge, black magic, what have you).  I just want to make
sure that we don't end with the middle end having to know that address space
"56" has special meaning beyond what is encoded in the data layout. 
To say it differently, I want to make sure that a different frontend targeting a
different backend is not effected by the proposed changes.
Got it. :) Yes, we have no intention of teaching the middle end about these
address spaces. The usual rules around addrspacecast should apply.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20190731/8fcc564f/attachment.html>

By default, nothing.  (i.e. everything across AS is mayalias) But 
individual AS pairs may define alternate aliasing rules.  I don't know 
that we have a good way to make that plugable today though.

On 7/31/19 10:58 AM, paul.robinson at sony.com wrote:
>
> I really hate to dip my toe in here, because it will only reveal my 
> total ignorance, but….
>
> Do the "usual rules around addrspacecast" say when different
address
> spaces can alias?  I remember somebody using address spaces to 
> represent something like special off-to-the-side device memory, which 
> obviously could never alias main memory, whereas other uses like the 
> 32/64-bit thing will certainly have the 32-bit space aliasing (likely 
> disjoint parts of) the 64-bit space, and the exact mapping of 32-to-64 
> might vary across OSes.
>
> --paulr
>
> *From:*llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] *On Behalf Of 
> *Reid Kleckner via llvm-dev
> *Sent:* Wednesday, July 31, 2019 1:44 PM
> *To:* Philip Reames
> *Cc:* llvm-dev; John Reagan
> *Subject:* Re: [llvm-dev] [RFC] Changing X86 data layout for address 
> spaces
>
> On Wed, Jul 31, 2019 at 10:29 AM Philip Reames via llvm-dev 
> <llvm-dev at lists.llvm.org <mailto:llvm-dev at
lists.llvm.org>> wrote:
>
>     Looks like I made my point in an accidentally really confusing
>     way.  Let me try again w/Matt's correction in mind.
>
>     I want to make sure that the middle end optimizer code is *driven
>     by the data layout*.  I am not trying to express an opinion on how
>     that data layout is populated (frontend, backedge, black magic,
>     what have you).  I just want to make sure that we don't end with
>     the middle end having to know that address space "56" has
special
>     meaning beyond what is encoded in the data layout.  To say it
>     differently, I want to make sure that a different frontend
>     targeting a different backend is not effected by the proposed changes.
>
> Got it. :) Yes, we have no intention of teaching the middle end about 
> these address spaces. The usual rules around addrspacecast should apply.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20190731/60517da5/attachment.html>

(forgot to llvm-dev…)

Would it make sense to have TTI answer queries about whether two address spaces
may alias? This is something I’ve asked myself in the past, but I’m not sure if
it follows the philosophy of what TTI should do.


From: llvm-dev <llvm-dev-bounces at lists.llvm.org> On Behalf Of Philip
Reames via llvm-dev
Sent: Wednesday, July 31, 2019 2:35 PM
To: paul.robinson at sony.com; rnk at google.com
Cc: llvm-dev at lists.llvm.org; john.reagan at vmssoftware.com
Subject: Re: [llvm-dev] [RFC] Changing X86 data layout for address spaces


By default, nothing.  (i.e. everything across AS is mayalias)  But individual AS
pairs may define alternate aliasing rules.  I don't know that we have a good
way to make that plugable today though.
On 7/31/19 10:58 AM, paul.robinson at sony.com<mailto:paul.robinson at
sony.com> wrote:
I really hate to dip my toe in here, because it will only reveal my total
ignorance, but….

Do the "usual rules around addrspacecast" say when different address
spaces can alias?  I remember somebody using address spaces to represent
something like special off-to-the-side device memory, which obviously could
never alias main memory, whereas other uses like the 32/64-bit thing will
certainly have the 32-bit space aliasing (likely disjoint parts of) the 64-bit
space, and the exact mapping of 32-to-64 might vary across OSes.
--paulr

From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On Behalf Of Reid
Kleckner via llvm-dev
Sent: Wednesday, July 31, 2019 1:44 PM
To: Philip Reames
Cc: llvm-dev; John Reagan
Subject: Re: [llvm-dev] [RFC] Changing X86 data layout for address spaces

On Wed, Jul 31, 2019 at 10:29 AM Philip Reames via llvm-dev <llvm-dev at
lists.llvm.org<mailto:llvm-dev at lists.llvm.org>> wrote:

Looks like I made my point in an accidentally really confusing way.  Let me try
again w/Matt's correction in mind.

I want to make sure that the middle end optimizer code is *driven by the data
layout*.  I am not trying to express an opinion on how that data layout is
populated (frontend, backedge, black magic, what have you).  I just want to make
sure that we don't end with the middle end having to know that address space
"56" has special meaning beyond what is encoded in the data layout. 
To say it differently, I want to make sure that a different frontend targeting a
different backend is not effected by the proposed changes.
Got it. :) Yes, we have no intention of teaching the middle end about these
address spaces. The usual rules around addrspacecast should apply.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20190801/be672a47/attachment.html>