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

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>

>
>   *Clang* can assign whatever meaning to an AS it wishes, and their
> properties are configurable via data layout configuration.

I think Clang checks that its data layout matches the LLVM target data
layout, so I'm not sure how to go about implementing the address spaces as
a change in Clang.
Thoughts?

The other issue I was running into is how to do the address space casts in
clang - my current thought was to lower the address space casts in LLVM to
the sign extension / zero extension / truncation.

Thanks,
Amy

On Mon, Jul 22, 2019 at 5:06 PM Philip Reames via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> 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> 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
>>
>
> _______________________________________________
> LLVM Developers mailing listllvm-dev at
lists.llvm.orghttps://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/20190726/cf267938/attachment.html>

That is basically what we do today to provide mixed sized pointers with
our legacy frontends.  They generate IR to our old code generator which
has ADDR32 and ADDR64 datatypes.  We use a 64-bit address data layout
and then typecast the 32-bit forms to/from the underlying 64-bit
addresses.  I have been warned that such rampant typecasting might
interfere with certain optimizations or TBAA data.  We haven't
investigated that yet.  Since clang doesn't go through our IR-to-IR
converter, we'll have to teach clang to do the same.

On 7/26/2019 6:35 PM, Amy Huang wrote:
>       *Clang* can assign whatever meaning to an AS it wishes, and their
>     properties are configurable via data layout configuration. 
> 
>  
> I think Clang checks that its data layout matches the LLVM target data
> layout, so I'm not sure how to go about implementing the address spaces
> as a change in Clang.
> Thoughts?
> 
> The other issue I was running into is how to do the address space casts
> in clang - my current thought was to lower the address space casts in
> LLVM to the sign extension / zero extension / truncation.
> 
> Thanks,
> Amy
> 
> On Mon, Jul 22, 2019 at 5:06 PM Philip Reames via llvm-dev
> <llvm-dev at lists.llvm.org <mailto:llvm-dev at
lists.llvm.org>> wrote:
> 
>     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 <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 <mailto:llvm-dev at lists.llvm.org>
>     https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
> 
-------------- 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/20190728/0f241066/attachment.sig>