Commit Graph

12 Commits

Author SHA1 Message Date
Erik Desjardins
96a72676d1 use [N x i8] for byval/sret types
This avoids depending on LLVM's struct types to determine the size of
the byval/sret slot.
2024-03-05 18:54:45 -05:00
许杰友 Jieyou Xu (Joe)
6e48b96692
[AUTO_GENERATED] Migrate compiletest to use ui_test-style //@ directives 2024-02-22 16:04:04 +00:00
Nikita Popov
c2fd26a115 Separate immediate and in-memory ScalarPair representation
Currently, we assume that ScalarPair is always represented using
a two-element struct, both as an immediate value and when stored
in memory.

This currently works fairly well, but runs into problems with
https://github.com/rust-lang/rust/pull/116672, where a ScalarPair
involving an i128 type can no longer be represented as a two-element
struct in memory. For example, the tuple `(i32, i128)` needs to be
represented in-memory as `{ i32, [3 x i32], i128 }` to satisfy
alignment requirement. Using `{ i32, i128 }` instead will result in
the second element being stored at the wrong offset (prior to
LLVM 18).

Resolve this issue by no longer requiring that the immediate and
in-memory type for ScalarPair are the same. The in-memory type
will now look the same as for normal struct types (and will include
padding filler and similar), while the immediate type stays a
simple two-element struct type. This also means that booleans in
immediate ScalarPair are now represented as i1 rather than i8,
just like we do everywhere else.

The core change here is to llvm_type (which now treats ScalarPair
as a normal struct) and immediate_llvm_type (which returns the
two-element struct that llvm_type used to produce). The rest is
fixing things up to no longer assume these are the same. In
particular, this switches places that try to get pointers to the
ScalarPair elements to use byte-geps instead of struct-geps.
2023-12-15 17:42:05 +01:00
Erik Desjardins
2daacf5af9 i686-windows: make requested alignment > 4 special case apply transitively 2023-07-14 17:48:13 -04:00
Erik Desjardins
7e933b4e26 repr(align) <= 4 should still be byval 2023-07-10 19:19:40 -04:00
Erik Desjardins
f704396c0e align-byval test: add cases for lower requested alignment, wrapped, and repr(transparent) 2023-07-10 19:19:39 -04:00
Erik Desjardins
0e76446a9f ensure byval allocas are sufficiently aligned 2023-07-10 19:19:38 -04:00
Erik Desjardins
209ed071ba align-byval test: add cases for <= align 4 2023-07-10 19:19:38 -04:00
Erik Desjardins
8ec90f6f14 align-byval test: add cases distinguishing natural vs forced/requested alignment 2023-07-10 19:19:37 -04:00
Erik Desjardins
08d18929fb align-byval test: add x86
x86 Windows also should not use byval since the struct is
overaligned, see https://reviews.llvm.org/D72114
2023-07-10 19:19:37 -04:00
Erik Desjardins
102292655b align-byval test: use revisions to test different targets 2023-07-10 19:19:35 -04:00
Patrick Walton
0becc89d4a rustc_target: Add alignment to indirectly-passed by-value types, correcting the
alignment of `byval` on x86 in the process.

Commit 88e4d2c291 from five years ago removed
support for alignment on indirectly-passed arguments because of problems with
the `i686-pc-windows-msvc` target. Unfortunately, the `memcpy` optimizations I
recently added to LLVM 16 depend on this to forward `memcpy`s. This commit
attempts to fix the problems with `byval` parameters on that target and now
correctly adds the `align` attribute.

The problem is summarized in [this comment] by @eddyb. Briefly, 32-bit x86 has
special alignment rules for `byval` parameters: for the most part, their
alignment is forced to 4. This is not well-documented anywhere but in the Clang
source. I looked at the logic in Clang `TargetInfo.cpp` and tried to replicate
it here. The relevant methods in that file are
`X86_32ABIInfo::getIndirectResult()` and
`X86_32ABIInfo::getTypeStackAlignInBytes()`. The `align` parameter attribute
for `byval` parameters in LLVM must match the platform ABI, or miscompilations
will occur. Note that this doesn't use the approach suggested by eddyb, because
I felt it was overkill to store the alignment in `on_stack` when special
handling is really only needed for 32-bit x86.

As a side effect, this should fix #80127, because it will make the `align`
parameter attribute for `byval` parameters match the platform ABI on LLVM
x86-64.

[this comment]: https://github.com/rust-lang/rust/pull/80822#issuecomment-829985417
2023-07-10 19:19:30 -04:00