John Reagan via llvm-dev
2019-Jul-22 19:08 UTC
[llvm-dev] [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>
Reid Kleckner via llvm-dev
2019-Jul-22 20:19 UTC
[llvm-dev] [RFC] Changing X86 data layout for address spaces
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>
Philip Reames via llvm-dev
2019-Jul-23 00:05 UTC
[llvm-dev] [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>