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

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20190722/a38412a0/attachment.sig>

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> 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
> 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/7ed2a966/attachment.html>

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>