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

[Arsenault, Matthew via llvm-dev]

I was addressing the concern about making an llvm backend change for this feature. From my perspective these are the same thing. There is one datalayout that should be consistent everywhere, regardless of the implementation details of how clang sets it on the module. This should definitely use a different sized address space. I don’t think there should be any real problem changing the datalayout, though there may need to be some long overdue datalayout upgrade work (e.g  IIRC llvm-link warns about mismatched datalayouts based on a dumb string comparison)

-Matt

________________________________
From: Reid Kleckner <rnk at google.com>
Sent: Wednesday, July 31, 2019 12:31
To: Arsenault, Matthew
Cc: Philip Reames; Amy Huang; John Reagan; llvm-dev
Subject: Re: [llvm-dev] [RFC] Changing X86 data layout for address spaces

On Wed, Jul 31, 2019 at 9:26 AM Arsenault, Matthew via llvm-dev <llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>> wrote:
The datalayout itself is currently not considered a point of configurability. It’s a static, backend/codegen defined property. The target machine machine returns the datalayout for the given triple and is the source of truth. The front end is responsible for creating a module with an exactly matching datalayout and is not free to customize the datalayout this way. I’m not sure what there is to gain by avoiding putting this information in the backend.

I agree with everything here, but did you mean frontend instead of backend in the last sentence? As a consequence of the fact that each target defines its data layout, that means we have to put the new data layout in the backend and the frontend if we are going to use address spaces.

We could implement this purely in the frontend with ptrotoint / inttoptr, zext, sext, trunc, i32, i64 etc, but the IR for it is quite awful and unoptimizable. It breaks several invariants and the extension seems to be naturally representable with address spaces.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20190731/29eccfc4/attachment-0001.html>