Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Separate immediate and in-memory ScalarPair representation #118991

Merged
merged 3 commits into from
Jan 5, 2024

Commits on Dec 15, 2023

  1. 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
    rust-lang#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.
    nikic committed Dec 15, 2023
    Configuration menu
    Copy the full SHA
    c2fd26a View commit details
    Browse the repository at this point in the history

Commits on Jan 2, 2024

  1. Address review comments

    nikic committed Jan 2, 2024
    Configuration menu
    Copy the full SHA
    8e64fc9 View commit details
    Browse the repository at this point in the history

Commits on Jan 5, 2024

  1. Configuration menu
    Copy the full SHA
    3cd6cde View commit details
    Browse the repository at this point in the history