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

Philip Reames via llvm-dev llvm-dev at lists.llvm.org
Mon Jul 22 17:05:58 PDT 2019


Please don't bake in knowledge *in LLVM* of a address space unless 
there's a strong need.  *Clang* can assign whatever meaning to an AS it 
wishes, and their properties are configurable via data layout 
configuration.

The standards of review are much lower for a Clang only change as it can 
be revised arbitrarily without breaking other uses of LLVM.  Building in 
first class knowledge to LLVM itself is a breaking change (potentially) 
for other frontends.

Philip

On 7/22/19 1:19 PM, Reid Kleckner via llvm-dev wrote:
> Yes, the address spaces are intended to be generally useful for other 
> applications. Glad to hear that you would find it useful. :)
>
> For now we were only going to add them for x86, but it should be easy 
> to add such address spaces to other targets.
>
> On Mon, Jul 22, 2019 at 1:13 PM John Reagan via llvm-dev 
> <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote:
>
>     Amy, when you say "implement MSVC's extensions", is that MSVC/LLVM or
>     are you going to add these to clang?  OpenVMS has dual-sized
>     pointers as
>     well and want to see them in clang.  One of my engineers noticed that
>     address space 4 was a 32-bit pointer address space (or at least it
>     used
>     to be).  I haven't seen any formal discussion of that over in the cfe
>     dev list.  I'm happy to help out where we can.
>
>     John
>
>     _______________________________________________
>     LLVM Developers mailing list
>     llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>
>     https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
>
> _______________________________________________
> 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/20190722/35482840/attachment.html>


More information about the llvm-dev mailing list