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

[Amy Huang via llvm-dev]

>
>   *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>