https://github.com/rust-lang/rust http://git.dreamy.place/mirrors/rust/atom?h=1.76.0 2023-07-27T21:44:13+00:00 2023-07-27T21:44:13+00:00 Josh Stone jistone@redhat.com 2023-07-27T21:44:13+00:00 urn:sha1:da47736f42307e450a447889ebc563cddaf93ac2 2023-07-10T23:19:30+00:00 Patrick Walton pcwalton@fb.com 2022-11-01T03:38:40+00:00 urn:sha1:0becc89d4a75d14571b02fb34ec1e3a45c9fb9dc alignment of `byval` on x86 in the process. Commit 88e4d2c2918428d55e34cd57c11279ea839c8822 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-08T13:38:40+00:00 Camille GILLOT gillot.camille@gmail.com 2023-05-15T19:15:28+00:00 urn:sha1:d7983a2f231a279984fc70eb428b936930eaa45c 2023-02-06T10:46:32+00:00 Ralf Jung post@ralfj.de 2022-12-27T11:31:17+00:00 urn:sha1:201ae7387245caa4591d4c8db4c35c170c64faf0 The code that consumes PointerKind (`adjust_for_rust_scalar` in rustc_ty_utils) ended up using PointerKind variants to talk about Rust reference types (& and &mut) anyway, making the old code structure quite confusing: one always had to keep in mind which PointerKind corresponds to which type. So this changes PointerKind to directly reflect the type. This does not change behavior. 2023-01-11T09:32:08+00:00 Albert Larsan 74931857+albertlarsan68@users.noreply.github.com 2023-01-05T08:13:28+00:00 urn:sha1:cf2dff2b1e3fa55fa5415d524200070d0d7aacfe