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

[Amy Huang via llvm-dev]

Sorry, this thread disappeared into my email filters.

So to clarify/summarize, the proposed change here is to change the x86
backend data layout to encode the pointer sizes for these three address
spaces. It seems like there's general agreement that this is fine, as long
as there aren't other changes to the 'middle end'--

On Wed, Jul 31, 2019 at 10:44 AM Reid Kleckner <rnk at google.com> wrote:

> On Wed, Jul 31, 2019 at 10:29 AM Philip Reames via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
>
>> Looks like I made my point in an accidentally really confusing way.  Let
>> me try again w/Matt's correction in mind.
>>
>> I want to make sure that the middle end optimizer code is *driven by the
>> data layout*.  I am not trying to express an opinion on how that data
>> layout is populated (frontend, backedge, black magic, what have you).  I
>> just want to make sure that we don't end with the middle end having to know
>> that address space "56" has special meaning beyond what is encoded in the
>> data layout.  To say it differently, I want to make sure that a different
>> frontend targeting a different backend is not effected by the proposed
>> changes.
>>
> Got it. :) Yes, we have no intention of teaching the middle end about
> these address spaces. The usual rules around addrspacecast should apply.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20190808/cac26a9a/attachment.html>