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

[Reid Kleckner via llvm-dev]

On Wed, Jul 31, 2019 at 9:26 AM Arsenault, Matthew via llvm-dev <
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/183fac9d/attachment.html>