Cast allocas to default address space

[Flakebi]

Pointers for variables all need to be in the same address space for correct compilation. Therefore ensure that even if an alloca is created in a different address space, it is casted to the default address space before its value is used.

This is necessary for the amdgpu target and others where the default address space for allocas is not 0.

For example the following code compiles incorrectly when not casting the address space to the default one:

fn f(p: *const i8 /* addrspace(0) */) -> *const i8 /* addrspace(0) */ {
    let local = 0i8; /* addrspace(5) */
    let res = if cond { p } else { &raw const local };
    res
}

results in

    %local = alloca addrspace(5) i8
    %res = alloca addrspace(5) ptr

if:
    ; Store 64-bit flat pointer
    store ptr %p, ptr addrspace(5) %res

else:
    ; Store 32-bit scratch pointer
    store ptr addrspace(5) %local, ptr addrspace(5) %res

ret:
    ; Load and return 64-bit flat pointer
    %res.load = load ptr, ptr addrspace(5) %res
    ret ptr %res.load

For amdgpu, addrspace(0) are 64-bit pointers, addrspace(5) are 32-bit pointers.
The above code may store a 32-bit pointer and read it back as a 64-bit pointer, which is obviously wrong and cannot work. Instead, we need to addrspacecast %local to ptr addrspace(0), then we store and load the correct type.

Tracking issue: #135024

[rustbot]

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @compiler-errors (or someone else) some time within the next two weeks.

Please see the contribution instructions for more information. Namely, in order to ensure the minimum review times lag, PR authors and assigned reviewers should ensure that the review label (S-waiting-on-review and S-waiting-on-author) stays updated, invoking these commands when appropriate:

• @rustbot author: the review is finished, PR author should check the comments and take action accordingly
• @rustbot review: the author is ready for a review, this PR will be queued again in the reviewer's queue

[compiler-errors]

Isn't this going to add a redundant addrspace cast for LLVM targets that don't care about this?

[Flakebi]

Isn't this going to add a redundant addrspace cast for LLVM targets that don't care about this?

No, LLVM checks itself if the cast is needed or not. So, if we checked this here, we would check twice in the case the cast is needed.

The code in LLVM is here:
https://github.com/llvm/llvm-project/blob/dd30aa83aa12e5b2b5e58cb72ec85070f725df34/llvm/include/llvm/IR/IRBuilder.h#L2201-L2204

The code for constant casts is here:
https://github.com/llvm/llvm-project/blob/dd30aa83aa12e5b2b5e58cb72ec85070f725df34/llvm/lib/IR/Instructions.cpp#L3041-L3042
(The Create(Instruction::BitCast, …) below is also a no-op if the types are already equal.)

[compiler-errors]

Maybe r? nikic

Or reassign

[nikic]

LGTM, but I think we should have a codegen test for this, which is presumably only possible after the amdgpu target has landed?

[Flakebi]

LGTM, but I think we should have a codegen test for this, which is presumably only possible after the amdgpu target has landed?

Yes, I don’t think I can add one otherwise. Rust rejects datalayout that do not match the LLVM one, so I can’t create a custom target file that has a non-0 default addrspace for allocas.

[Flakebi]

For what it’s worth, I wrote a test here: Flakebi@38de6b7
Merging the amdgpu target seems to take a while longer because some CI jobs run out of disk space with the additional LLVM target.

[Flakebi]

The target is merged, so the test should pass now 🥳
Diff (just added the test)

[Flakebi]

Now using add-core-stubs in the test. Diff

[nikic]

@bors r+

[bors]

📌 Commit cde7e80 has been approved by nikic

It is now in the queue for this repository.