Make `librustc_codegen_llvm` aware of LLVM address spaces.#51576

DiamondLovesYou · 2018-06-15T15:12:46Z

In order to not require overloading functions based on their argument's address
space (among other things), we require the presence of a "flat" (ie an address
space which is shared with every other address space) address space.

This isn't exposed in any way to Rust code. This just makes Rust compatible with
LLVM target machines which, for example, place allocas in a different address
space. amdgcn-amd-amdhsa-amdgiz is a specific example, which places allocas in
address space 5 or the private (at the work item level) address space. This
includes working with nonuniform sized pointers.

rust-highfive · 2018-06-15T15:12:49Z

r? @petrochenkov

(rust_highfive has picked a reviewer for you, use r? to override)

Mark-Simulacrum

The rustbuild changes look acceptable to me.

Mark-Simulacrum · 2018-06-15T16:31:30Z

src/bootstrap/native.rs

There should be no need for this here as AFAICT it's always globally set, we never do anything but pass it in from config.llvm_dump_enabled.

Mark-Simulacrum · 2018-06-15T16:32:26Z

src/librustc_codegen_llvm/builder.rs

This looks wrong.

Mark-Simulacrum · 2018-06-15T16:36:44Z

src/librustc_target/Cargo.toml

I don't see this dependency actually being used -- but maybe I'm missing something?

rustc_target shouldn't have any dependencies on the compiler, so hopefully this is unused.

It is used for custom address space names.

Oh, it was. I forgot I had removed it.

Mark-Simulacrum · 2018-06-15T16:37:04Z

r? @eddyb probably

eddyb · 2018-06-15T17:18:19Z

src/librustc_errors/lib.rs

cc @nikomatsakis

eddyb · 2018-06-15T17:20:19Z

cc @alexcrichton

~~I'm still reading, but some of the details seem a bit more invasive than I expected.~~ reviewed

eddyb · 2018-06-15T17:21:30Z

src/librustc_codegen_llvm/Cargo.toml

Missing newline at the end of file.

eddyb · 2018-06-15T17:22:40Z

src/librustc_codegen_llvm/abi.rs

If this is common, wouldn't a replacement for pointercast that only casts the pointee, but preserves the AS, be better?

eddyb · 2018-06-15T17:25:00Z

src/librustc_codegen_llvm/abi.rs

Instead of having a method to retrieve a specific AS and then another to create a pointer type, why not have e.g. .alloca_ptr_to(cx) or .ptr_to(cx, AddrSpaceKind::Alloca) (okay, the latter is a bit long).

I actually already have those functions, I just probably added them after I wrote some of this 😄

eddyb · 2018-06-15T17:26:52Z

src/librustc_codegen_llvm/abi.rs

By "dst" you mean "slice (length)"? Also, I should note this doesn't necessarily work.
The pair could just as well be (&T, &U) where T: Sized, U: Sized.

A better approach might be to pass something extra to scalar_pair_element_llvm_type. Same for everything else, really.

eddyb · 2018-06-15T17:28:35Z

src/librustc_codegen_llvm/base.rs

Same here, regarding the usecase of only needed to cast the pointee type.

eddyb · 2018-06-15T17:29:16Z

src/librustc_codegen_llvm/builder.rs

cc @nikomatsakis

eddyb · 2018-06-15T17:30:40Z

src/librustc_codegen_llvm/common.rs

Maybe pass the AddrSpaceKind enum value around instead of the LLVM AS number?

eddyb · 2018-06-15T17:31:23Z

src/librustc_codegen_llvm/consts.rs

There shouldn't be that many calls, making this non-optional (and using AddrSpaceKind) would be better IMO.

eddyb · 2018-06-15T17:32:25Z

src/librustc_codegen_llvm/context.rs

We probably shouldn't have cached types like these.

eddyb · 2018-06-15T17:33:01Z

src/librustc_codegen_llvm/context.rs

I think this is worse, because it incurs extra branching. Might as well switch it to String.

eddyb · 2018-06-15T17:33:52Z

src/librustc_codegen_llvm/context.rs

memcpy has a dot at the end, but the others don't?

eddyb · 2018-06-15T17:35:13Z

src/librustc_codegen_llvm/mir/operand.rs

Why would these two be needed?

eddyb · 2018-06-15T17:36:07Z

src/librustc_codegen_llvm/mir/place.rs

Again, could have a pointercast variant that only casts the pointee.

eddyb · 2018-06-15T17:36:18Z

src/librustc_codegen_llvm/mir/place.rs

eddyb · 2018-06-15T17:36:47Z

src/librustc_codegen_llvm/mir/rvalue.rs

Superfluous , .

eddyb · 2018-06-15T17:43:48Z

src/librustc_codegen_llvm/mir/rvalue.rs

What is this all doing? Why would the function being called here ever return by indirection?

Accidentally included. Was created when I was trying to figure out how to work with the AMDGPU target machine. I tried having every function be the amdgpu kernel abi, which doesn't allow non-void return types.

Removed in the next version, to be pushed Soon(TM).

eddyb · 2018-06-15T17:46:40Z

src/librustc_codegen_llvm/mono_item.rs

We should avoid touching the HIR here, but it's not clear what requirements there actually are.

We need the address space of the global for the global's LLVM type, meaning it needs to compute the same address space as consts::codegen_static.

At the time, I wasn't aware of a better way, but the next version now does what MonoItemExt::define does.

eddyb · 2018-06-15T17:47:06Z

src/librustc_codegen_llvm/type_.rs

Why all of these? We should avoid introspecting LLVM types at all costs IMO.

eddyb

I don't see how any of the code around read-only and read-write global address spaces, actually works. Why are vtable pointers different from any other pointer?
If there is a flat address space, why isn't it used more often? Some documentation would help.

I hope there is a simpler way to support the target platform you want.

mati865 · 2018-12-10T11:39:41Z

This PR was labelled as Blocked 2 months ago:

Waiting on people to be freed up from work on the 2018 edition

@BatmanAoD is it still the case?

emilyalbini · 2018-12-11T13:36:21Z

Review ping @eddyb

bors · 2018-12-13T03:35:24Z

☔ The latest upstream changes (presumably #55982) made this pull request unmergeable. Please resolve the merge conflicts.

jrtc27 · 2018-12-22T02:35:41Z

src/librustc_codegen_llvm/context.rs

Should be Instruction

Good catch, thanks

jrtc27 · 2018-12-22T02:36:49Z

src/librustc_target/spec/mod.rs

Missing Instruction?

bors · 2018-12-26T19:07:13Z

☔ The latest upstream changes (presumably #57108) made this pull request unmergeable. Please resolve the merge conflicts.

bors · 2019-01-05T17:40:09Z

☔ The latest upstream changes (presumably #57145) made this pull request unmergeable. Please resolve the merge conflicts.

bors · 2019-01-16T15:16:20Z

☔ The latest upstream changes (presumably #57416) made this pull request unmergeable. Please resolve the merge conflicts.

In order to not require overloading functions based on their argument's address space (among other things), we require the presence of a "flat" (ie an address space which is shared with every other address space) address space. This isn't exposed in any way to Rust code. This just makes Rust compatible with LLVM target machines which, for example, place allocas in a different address space. `amdgcn-amd-amdhsa-amdgiz` is a specific example, which places allocas in address space 5 or the private (at the work item level) address space.

…l address space where possible.

bors · 2019-02-09T03:54:43Z

☔ The latest upstream changes (presumably #58316) made this pull request unmergeable. Please resolve the merge conflicts.

Dylan-DPC-zz · 2019-03-04T18:54:41Z

ping from triage @DiamondLovesYou you have conflicts you need to resolve

Dylan-DPC-zz · 2019-03-11T22:20:31Z

ping from triage @DiamondLovesYou
Unfortunately we haven't heard from you on this in a while, so I'm closing the PR to keep things tidy. Don't worry though, if you'll have time again in the future please reopen this PR, we'll be happy to review it again! Thanks for contirbuting!

rust-highfive assigned petrochenkov Jun 15, 2018

rust-highfive added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Jun 15, 2018

DiamondLovesYou mentioned this pull request Jun 15, 2018

Tracking issue for targeting AMDGPU devices #51575

Closed

5 tasks

Mark-Simulacrum reviewed Jun 15, 2018

View reviewed changes

rust-highfive assigned eddyb and unassigned petrochenkov Jun 15, 2018