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

[Philip Reames via llvm-dev]

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>