[WebAssembly] Add `-i128:128` to the `datalayout` string. (#119204)

Clang [defaults to aligning `__int128_t` to 16 bytes], while LLVM
`datalayout` strings [default to aligning `i128` to 8 bytes]. W

[WebAssembly] Add `-i128:128` to the `datalayout` string. (#119204)

Clang [defaults to aligning `__int128_t` to 16 bytes], while LLVM
`datalayout` strings [default to aligning `i128` to 8 bytes]. Wasm is
currently using the defaults for both, so it's inconsistent. Fix this by
adding `-i128:128` to Wasm's `datalayout` string so that it aligns
`i128` to 16 bytes too.

This is similar to
[llvm/llvm-project@dbad963](https://github.com/llvm/llvm-project/commit/dbad963a69fd7b16c6838f81b61167fbf00a413c)
for SPARC.

This fixes rust-lang/rust#133991; see that issue for further discussion.

[defaults to aligning `__int128_t` to 16 bytes]:
https://github.com/llvm/llvm-project/blob/f8b4182f076f8fe55f9d5f617b5a25008a77b22f/clang/lib/Basic/TargetInfo.cpp#L77
[default to aligning `i128` to 8 bytes]:
https://llvm.org/docs/LangRef.html#langref-datalayout

show more ...

[PowerPC] Update data layout aligment of i128 to 16 (#118004)

Fix 64-bit PowerPC part of
https://github.com/llvm/llvm-project/issues/102783.

[MIPS] LLVM data layout give i128 an alignment of 16 for mips64 (#112084)

Fix parts of #102783.

[clang][aarch64] Add support for the MSVC qualifiers __ptr32, __ptr64, __sptr, __uptr for AArch64 (#111879)

MSVC has a set of qualifiers to allow using 32-bit signed/unsigned
pointers when building

[clang][aarch64] Add support for the MSVC qualifiers __ptr32, __ptr64, __sptr, __uptr for AArch64 (#111879)

MSVC has a set of qualifiers to allow using 32-bit signed/unsigned
pointers when building 64-bit targets. This is useful for WoW code
(i.e., the part of Windows that handles running 32-bit application on a
64-bit OS). Currently this is supported on x64 using the 270, 271 and
272 address spaces, but does not work for AArch64 at all.

This change adds the same 270, 271 and 272 address spaces to AArch64 and
adjusts the data layout string accordingly. Clang will generate the
correct address space casts, but these will currently be ignored until
the AArch64 backend is updated to handle them.

Partially fixes #62536

This is a resurrected version of <https://reviews.llvm.org/D158857>
(originally created by @a_vorobev) - I've cleaned it up a little, fixed
the rest of the tests and added to auto-upgrade for the data layout.

show more ...

[SPARC] Align i128 to 16 bytes in SPARC datalayouts (#106951)

Align i128s to 16 bytes, following the example at
https://reviews.llvm.org/D86310.

clang already does this implicitly, but do it in

[SPARC] Align i128 to 16 bytes in SPARC datalayouts (#106951)

Align i128s to 16 bytes, following the example at
https://reviews.llvm.org/D86310.

clang already does this implicitly, but do it in backend code too for
the benefit of other frontends (see e.g
https://github.com/llvm/llvm-project/issues/102783 &
https://github.com/rust-lang/rust/issues/128950).

show more ...

[LoongArch] Adjust LA64 data layout by using n32:64 in layout string (#93814)

Although i32 type is illegal in the backend, LA64 has pretty good
support for i32 types by using W instructions.

By

[LoongArch] Adjust LA64 data layout by using n32:64 in layout string (#93814)

Although i32 type is illegal in the backend, LA64 has pretty good
support for i32 types by using W instructions.

By adding n32 to the DataLayout string, middle end optimizations will
consider i32 to be a native type. One known effect of this is enabling
LoopStrengthReduce on loops with i32 induction variables. This can be
beneficial because C/C++ code often has loops with i32 induction
variables due to the use of `int` or `unsigned int`.

If this patch exposes performance issues, those are better addressed by
tuning LSR or other passes.

show more ...

[clang backend] In AArch64's DataLayout, specify a minimum function alignment of 4. (#90702)

This addresses an issue where the explicit alignment of 2 (for C++ ABI
reasons) was being propagated to

[clang backend] In AArch64's DataLayout, specify a minimum function alignment of 4. (#90702)

This addresses an issue where the explicit alignment of 2 (for C++ ABI
reasons) was being propagated to the back end and causing under-aligned
functions (in special sections).

This is an alternate approach suggested by @efriedma-quic in PR #90415.

Fixes #90358

show more ...

[clang][CodeGen] Add AS for Globals to SPIR & SPIRV datalayouts (#88455)

Currently neither the SPIR nor the SPIRV targets specify the AS for
globals in their datalayout strings. This is problematic

[clang][CodeGen] Add AS for Globals to SPIR & SPIRV datalayouts (#88455)

Currently neither the SPIR nor the SPIRV targets specify the AS for
globals in their datalayout strings. This is problematic because
CodeGen/LLVM will default to AS0 in this case, which produces Globals
that end up in the private address space for e.g. OCL, HIPSPV or SYCL.
This patch addresses it by completing the datalayout string.

show more ...

[AMDGPU] - Add address space for strided buffers (#74471)

This is an experimental address space for strided buffers. These buffers
can have structs as elements and
a stride > 1.
These pointers al

[AMDGPU] - Add address space for strided buffers (#74471)

This is an experimental address space for strided buffers. These buffers
can have structs as elements and
a stride > 1.
These pointers allow the indexed access in units of stride, i.e., they
point at `buffer[index * stride]`.
Thus, we can use the `idxen` modifier for buffer loads.

We assign address space 9 to 192-bit buffer pointers which contain a
128-bit descriptor, a 32-bit offset and a 32-bit index. Essentially,
they are fat buffer pointers with an additional 32-bit index.

show more ...

[X86] Align i128 to 16 bytes in x86 datalayouts

This is an attempt at rebooting https://reviews.llvm.org/D28990

I've included AutoUpgrade changes to modify the data layout to satisfy the compatible

[X86] Align i128 to 16 bytes in x86 datalayouts

This is an attempt at rebooting https://reviews.llvm.org/D28990

I've included AutoUpgrade changes to modify the data layout to satisfy the compatible layout check. But this does mean alloca, loads, stores, etc in old IR will automatically get this new alignment.

This should fix PR46320.

Reviewed By: echristo, rnk, tmgross

Differential Revision: https://reviews.llvm.org/D86310

show more ...

Re-land "[AMDGPU] Define data layout entries for buffers""

Re-land D145441 with data layout upgrade code fixed to not break OpenMP.

This reverts commit 3f2fbe92d0f40bcb46db7636db9ec3f7e7899b27.

Di

Re-land "[AMDGPU] Define data layout entries for buffers""

Re-land D145441 with data layout upgrade code fixed to not break OpenMP.

This reverts commit 3f2fbe92d0f40bcb46db7636db9ec3f7e7899b27.

Differential Revision: https://reviews.llvm.org/D149776

show more ...

Revert "[AMDGPU] Define data layout entries for buffers"

This reverts commit f9c1ede2543b37fabe9f2d8f8fed5073c475d850.

Differential Revision: https://reviews.llvm.org/D149758

[AMDGPU] Define data layout entries for buffers

Per discussion at
https://discourse.llvm.org/t/representing-buffer-descriptors-in-the-amdgpu-target-call-for-suggestions/68798,
we define two new addr

[AMDGPU] Define data layout entries for buffers

Per discussion at
https://discourse.llvm.org/t/representing-buffer-descriptors-in-the-amdgpu-target-call-for-suggestions/68798,
we define two new address spaces for AMDGCN targets.

The first is address space 7, a non-integral address space (which was
already in the data layout) that has 160-bit pointers (which are
256-bit aligned) and uses a 32-bit offset. These pointers combine a
128-bit buffer descriptor and a 32-bit offset, and will be usable with
normal LLVM operations (load, store, GEP). However, they will be
rewritten out of existence before code generation.

The second of these is address space 8, the address space for "buffer
resources". These will be used to represent the resource arguments to
buffer instructions, and new buffer intrinsics will be defined that
take them instead of <4 x i32> as resource arguments. ptr
addrspace(8). These pointers are 128-bits long (with the same
alignment). They must not be used as the arguments to getelementptr or
otherwise used in address computations, since they can have
arbitrarily complex inherent addressing semantics that can't be
represented in LLVM. Even though, like their address space 7 cousins,
these pointers have deterministic ptrtoint/inttoptr semantics, they
are defined to be non-integral in order to prevent optimizations that
rely on pointers being a [0, [addr_max]] value from applying to them.

Future work includes:
- Defining new buffer intrinsics that take ptr addrspace(8) resources.
- A late rewrite to turn address space 7 operations into buffer
intrinsics and offset computations.

This commit also updates the "fallback address space" for buffer
intrinsics to the buffer resource, and updates the alias analysis
table.

Depends on D143437

Reviewed By: arsenm

Differential Revision: https://reviews.llvm.org/D145441

show more ...

[RISCV] Adjust RV64I data layout by using n32:64 in layout string

Although i32 type is illegal in the backend, RV64I has pretty good support for i32 types by using W instructions.

By adding n32 to

[RISCV] Adjust RV64I data layout by using n32:64 in layout string

Although i32 type is illegal in the backend, RV64I has pretty good support for i32 types by using W instructions.

By adding n32 to the DataLayout string, middle end optimizations will consider i32 to be a native type. One known effect of this is enabling LoopStrengthReduce on loops with i32 induction variables. This can be beneficial because C/C++ code often has loops with i32 induction variables due to the use of `int` or `unsigned int`.

If this patch exposes performance issues, those are better addressed by tuning LSR or other passes.

Reviewed By: asb, frasercrmck

Differential Revision: https://reviews.llvm.org/D116735

show more ...

[X86][MS] Change the alignment of f80 to 16 bytes on Windows 32bits to match with ICC

MSVC currently doesn't support 80 bits long double. ICC supports it when
the option `/Qlong-double` is specified

[X86][MS] Change the alignment of f80 to 16 bytes on Windows 32bits to match with ICC

MSVC currently doesn't support 80 bits long double. ICC supports it when
the option `/Qlong-double` is specified. Changing the alignment of f80
to 16 bytes so that we can be compatible with ICC's option.

Reviewed By: rnk, craig.topper

Differential Revision: https://reviews.llvm.org/D115942

show more ...

Revert "[X86][MS] Change the alignment of f80 to 16 bytes on Windows 32bits to match with ICC"

This reverts commit 1bb0caf561688681be67cc91560348c9e43fcbf3.

[X86][MS] Change the alignment of f80 to 16 bytes on Windows 32bits to match with ICC

MSVC currently doesn't support 80 bits long double. ICC supports it when
the option `/Qlong-double` is specified

[X86][MS] Change the alignment of f80 to 16 bytes on Windows 32bits to match with ICC

MSVC currently doesn't support 80 bits long double. ICC supports it when
the option `/Qlong-double` is specified. Changing the alignment of f80
to 16 bytes so that we can be compatible with ICC's option.

Reviewed By: rnk, craig.topper

Differential Revision: https://reviews.llvm.org/D115942

show more ...

[AMDGPU] Set the default globals address space to 1

This will ensure that passes that add new global variables will create them
in address space 1 once the passes have been updated to no longer defa

[AMDGPU] Set the default globals address space to 1

This will ensure that passes that add new global variables will create them
in address space 1 once the passes have been updated to no longer default
to the implicit address space zero.
This also changes AutoUpgrade.cpp to add -G1 to the DataLayout if it wasn't
already to present to ensure bitcode backwards compatibility.

Reviewed by: arsenm

Differential Revision: https://reviews.llvm.org/D84345

show more ...

Add AutoUpgrade function to add new address space datalayout string to existing datalayouts.

Summary:
Add function to AutoUpgrade to change the datalayout of old X86 datalayout strings.
This adds "-

Add AutoUpgrade function to add new address space datalayout string to existing datalayouts.

Summary:
Add function to AutoUpgrade to change the datalayout of old X86 datalayout strings.
This adds "-p270:32:32-p271:32:32-p272:64:64" to X86 datalayouts that are otherwise valid
and don't already contain it.

This also removes the compatibility changes in https://reviews.llvm.org/D66843.
Datalayout change in https://reviews.llvm.org/D64931.

Reviewers: rnk, echristo

Subscribers: hiraditya, llvm-commits

Tags: #llvm

Differential Revision: https://reviews.llvm.org/D67631

llvm-svn: 372267

show more ...