Stream: t-compiler

Topic: address-space (ptr, ref)


Alex Koz. (Oct 30 2019 at 11:54, on Zulip):

Hi all! I'm working on full support address-spaces now.
So I'm stuck on limited size of Ty. Why it's limited to 32bit?
See: librustc/ty/mod.rs @ line 506 static_assert_size!(TyS<'_>, 32);

It's blocking me to add address_space field into RawPtr for example.
(And I can't use const-generics because it's really incomplete and unstable yet)

simulacrum (Oct 30 2019 at 11:56, on Zulip):

It's limited because the size of Ty should be kept small to decrease memory usage and increase speed

Alex Koz. (Oct 30 2019 at 11:59, on Zulip):

So now I have no idea how to impl it without extending that size. Any suggestions, ideas?

Alex Koz. (Oct 30 2019 at 12:00, on Zulip):

Can I increase size from 32 to 40? Is it will be ok?

simulacrum (Oct 30 2019 at 12:00, on Zulip):

Well, if it's required, obviously we _can_, it's just likely bad for perf

simulacrum (Oct 30 2019 at 12:03, on Zulip):

I think I've seen some other existing work in this area, maybe it's been by you, not sure

simulacrum (Oct 30 2019 at 12:03, on Zulip):

I would try and touch base with @eddyb (though they can be hard to reach, super busy) on this before doing much

eddyb (Oct 30 2019 at 12:42, on Zulip):

@Alex Koz. I'm sorry, but it's unlikely that you could upstream such a change without an RFC

eddyb (Oct 30 2019 at 12:43, on Zulip):

and I'm against landing anything invasive - there's already been an attempt and they didn't want to shrink it down to the minimum necessary to function

eddyb (Oct 30 2019 at 12:43, on Zulip):

and that's all pretty much hidden from the user, it would be hard to convince people that make the typesystem more complex is worth it

eddyb (Oct 30 2019 at 12:44, on Zulip):

@Alex Koz. you could, however, use const generics and a lang item, to experiment with some of this, and it would be less invasive

eddyb (Oct 30 2019 at 12:44, on Zulip):

maybe intrinsics to do the non-default-address-space operations

Alex Koz. (Oct 30 2019 at 14:24, on Zulip):

@eddyb Thanks for answer. I cannot use intrinsics because there's should be fn-params initially. For example something like this:

const ADDR_SPACE_FOO = 2;
type Color = [u32; 4]
extern "some-abi" fn my_compute_shader(buffer: Buf<Color, ADDR_SPACE_FOO>) { ... }
Alex Koz. (Oct 30 2019 at 14:31, on Zulip):

I'm sorry, but it's unlikely that you could upstream such a change without an RFC

Thanks, I know. Firstly I should try and off course I'll write an RFC :)

eddyb (Oct 30 2019 at 15:12, on Zulip):

an intrinsic like that would work I think

eddyb (Oct 30 2019 at 15:12, on Zulip):

although I'm not sure what you mean

Alex Koz. (Oct 30 2019 at 16:00, on Zulip):

@eddyb ,

I mean I need possibility somehow describe address-space for input args of function.
E.g.: if I wanna addrspace=42 for ptr in fn foo(ptr: *mut u128), so in llvm's IR ptr should be u128 addrspace(42)* .

So I have following options how to impl this:
- wrap type of ptr into lang-item something like AddressedPtr <T, const ADDR_SPACE: u32> and later evaluate constant in codegen;
- param-attr like fn foo( #[addrspace(42)] ptr: *mut u128) and wrap type and eval (see previous option);
- hack syntax, add something terrible ptr-syntax extension like *<42>mut u128 or *.42 mut u128 (really bad option).

What I have missed?

P.S: Sorry, my English isn't so cool. It's not native for me (yet).

Alex Koz. (Oct 30 2019 at 16:14, on Zulip):

For better explanation,
- Address space is an attr of pointer
- In low-level and compile-time, address space for various targets have various usage. For example in the AMDGPU it used for mapping to various physical memory "parts", but in Apple's Metal also for indicate mutability.
- For GPU-target (as minimum) we should expose API for create addresspace-ed pointers to user. I think it should be type-wrapper with const-generic in the libcore as I told before.

eddyb (Oct 30 2019 at 16:15, on Zulip):

- wrap type of ptr into lang-item something like AddressedPtr <T, const ADDR_SPACE: u32> and later evaluate constant in codegen;

this is what I was suggesting btw

eddyb (Oct 30 2019 at 16:16, on Zulip):

it avoids needing to change the typesystem

Alex Koz. (Oct 30 2019 at 16:19, on Zulip):

Thanks! I think so.

Alex Koz. (Oct 31 2019 at 13:00, on Zulip):

@eddyb May you help me with a little stuck? I added lang item in librustc/middle/lang_items.rs : language_item_table!

AddrspaceLangItem, "addrspace", addrspace, Target::Struct;

but anyway always getting error when libcore compilation: definition of an unknown language item: addrspace.
What I missed?

eddyb (Oct 31 2019 at 13:01, on Zulip):

you need to have #[cfg(not(bootstrap))] on it

eddyb (Oct 31 2019 at 13:01, on Zulip):

since the beta compiler doesn't know about it yet

nikomatsakis (Oct 31 2019 at 13:02, on Zulip):

I agree with @eddyb that this would require an RFC -- and in particular I'd like to understand better the motivation

eddyb (Oct 31 2019 at 13:03, on Zulip):

@nikomatsakis ignoring x86_16, which idk if anyone is working on, this tends to be limited to GPUs, which are designed to have N distinct memory spaces and I'm not even sure there's a way to have an unified pointer at all (like you can have a far pointer on x86_16)

eddyb (Oct 31 2019 at 13:04, on Zulip):

while compiling Rust to run on GPUs is cool, it's also... complicated

eddyb (Oct 31 2019 at 13:04, on Zulip):

I'd prefer us have the current typesystem and only add special types (or even just intrinsics in {core,std}::arch) for the "non-default" address spaces, but it may not be workable

eddyb (Oct 31 2019 at 13:06, on Zulip):

@nikomatsakis note that this is not about Harvard architectures (like AVR, I think? or a different one we support), which we already support by always keeping data pointers and fn pointers distinct during codegen (this is not that hard since the typesystem already distinguishes between them)

eddyb (Oct 31 2019 at 13:07, on Zulip):

and besides, data pointers use load/store, fn pointers use call, they're disjoint in their uses and the difference can be handled there trivially

eddyb (Oct 31 2019 at 13:08, on Zulip):

@nikomatsakis on top of that, all attempts I've seen at adding multiple data addrspaces to Rust (including from @Alex Koz.) explicitly mention GPUs

davidtwco (Oct 31 2019 at 13:10, on Zulip):

GPUs are the primary case where I'm familiar with address spaces. At $dayjob, we need to consider different address spaces in Clang for targeting GPUs (through OpenCL).

davidtwco (Oct 31 2019 at 13:12, on Zulip):

For the uses cases I'm familiar with specifically (and I'm by no means an expert in this stuff, but I do have some interest and would like to see Rust be usable in this space), address spaces of pointers are typically inferred during compilation.

davidtwco (Oct 31 2019 at 13:12, on Zulip):

Though some projects I'm aware of (that also target OpenCL) will use OpenCL 2.0's generic space exclusively and leave all inference to the OpenCL runtime.

eddyb (Oct 31 2019 at 13:13, on Zulip):

ooooh I'd prefer that if it's possible for LLVM to do it

eddyb (Oct 31 2019 at 13:13, on Zulip):

(i.e. if we don't have to do it in rustc)

davidtwco (Oct 31 2019 at 13:14, on Zulip):

That's not something that LLVM has currently, but I know people discussing the possibility (commercially, unlikely to ever be unstreamed).

eddyb (Oct 31 2019 at 13:14, on Zulip):

:scream:

eddyb (Oct 31 2019 at 13:15, on Zulip):

so who implements OpenCL 2 and how?!

davidtwco (Oct 31 2019 at 13:15, on Zulip):

Sometimes you do need to specify it in user code though, I've seen attributes in Clang (something like __attribute__((address_space(3))) used or types that are constructed like Option, but you have some GlobalAddrSpacePointer::new(/* some ptr type*/) which is either None or Some(/* ptr */) if that pointer was in the global address space.

davidtwco (Oct 31 2019 at 13:16, on Zulip):

Intel's SYCL implementation (https://github.com/intel/llvm) uses the generic address space for everything and then their OpenCL runtime does the inference (so they are OpenCL 2.0 only).

davidtwco (Oct 31 2019 at 13:16, on Zulip):

My employer's SYCL implementation does the address space inference in Clang, and so supports OpenCL <2.0 too.

davidtwco (Oct 31 2019 at 13:17, on Zulip):

(which is valuable, because some specialized hardware won't be able to support generic address spaces)

davidtwco (Oct 31 2019 at 13:18, on Zulip):

I don't know enough about this stuff from a end-user perspective (or implementer's perspective) to have a strong opinion on how much this type of detail should be surfaced to the user, or how possible it is to do it all without the user needing to care.

davidtwco (Oct 31 2019 at 13:23, on Zulip):

Intel's Compute Runtime (https://github.com/intel/compute-runtime) is an open-source implementation of OpenCL 2.1 for their integrated graphics hardware.

Alex Koz. (Oct 31 2019 at 13:23, on Zulip):

@eddyb:

you need to have #[cfg(not(bootstrap))] on it

Maybe I'm stupid more then I knew but it's not working. Also #[cfg_attr(not(bootstrap), lang = "addrspace")] too. Same error.
I added lang-item into the core lib, not in std.

davidtwco (Oct 31 2019 at 13:23, on Zulip):

I assume (again, I'm not that familiar with this stuff) that it does address space inference to support generic address spaces.

eddyb (Oct 31 2019 at 13:24, on Zulip):

@Alex Koz. can you search libcore for the word bootstrap?

eddyb (Oct 31 2019 at 13:25, on Zulip):

if you're not up to date it might be named something else, there were some issues for a bit

davidtwco (Oct 31 2019 at 13:25, on Zulip):

Alex Koz. can you search libcore for the word bootstrap?

Here's an example on tip right now.

Alex Koz. (Oct 31 2019 at 13:27, on Zulip):

Another example of address-spaces - AMDGPU target. There is various distinctions and ptr-sizes for each space. Also see mem-spaces.
https://llvm.org/docs/AMDGPUUsage.html#amdgpu-address-space-mapping-table

eddyb (Oct 31 2019 at 13:29, on Zulip):

@davidtwco it was named something else for a while, is why I'm asking

davidtwco (Oct 31 2019 at 13:29, on Zulip):

davidtwco it was named something else for a while, is why I'm asking

Yeah, I remember.

eddyb (Oct 31 2019 at 13:29, on Zulip):

@Alex Koz. that's not a different example, that's the same example I gave: GPUs

Alex Koz. (Oct 31 2019 at 13:32, on Zulip):

Screenshot-2019-10-31-at-16.32.01.png :(

eddyb (Oct 31 2019 at 13:33, on Zulip):

@Alex Koz. did you set anything in config.toml?

eddyb (Oct 31 2019 at 13:34, on Zulip):

@Alex Koz. also, can you grep src/libcore in your checkout for bootstrap?

Alex Koz. (Oct 31 2019 at 13:34, on Zulip):

@eddyb Yes but there's nothing about lang-items.

eddyb (Oct 31 2019 at 13:35, on Zulip):

@Alex Koz. doesn't matter, for both of my questions

eddyb (Oct 31 2019 at 13:36, on Zulip):

for config.toml, it's possible you're not building stage0 with the beta compiler, and for the grep thing it's to confirm that the cfg flag is indeed named bootstrap for you

nikomatsakis (Oct 31 2019 at 13:36, on Zulip):

@eddyb thanks -- I think this is a good and interesting case -- I'd like to enable exploration around GPUs (including tinkering with address spaces) but in a way where we give very low commitment

nikomatsakis (Oct 31 2019 at 13:36, on Zulip):

(and I agree i'd prefer to avoid invasive changes)

Alex Koz. (Oct 31 2019 at 13:37, on Zulip):

@eddyb Found just my #[cfg_attr(not(bootstrap), lang = "addrspace")]. I'm on the not latest commit - mb. problem in it...

eddyb (Oct 31 2019 at 13:38, on Zulip):

yeah, right now there are several uses of bootstrap, so if you don't see any others, you might be on one of the versions where it was named something hacky to bypass a bug

Alex Koz. (Oct 31 2019 at 13:39, on Zulip):

O! I understood. Thanks a lot! :D

Alex Koz. (Oct 31 2019 at 13:43, on Zulip):

@nikomatsakis : (and I agree i'd prefer to avoid invasive changes)

Sorry, I have no see any way to impl it without changes of RawPtr structure to store the specified address space.

But maybe I can create one more extra context where will be stored address space for each def?...

Alex Koz. (Oct 31 2019 at 13:44, on Zulip):

Also same for Ref but more complicated.

Alex Koz. (Oct 31 2019 at 13:46, on Zulip):

It because I don't want to change the codegen_llvm impl & api like fn type_ptr_to(&self, ty: &'ll Type) -> &'ll Type.

Alex Koz. (Nov 01 2019 at 16:09, on Zulip):

@nikomatsakis also ARMs http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dai0179b/CHDDBAEC.html

eddyb (Nov 01 2019 at 16:38, on Zulip):

that's a memory map of ono address space though?

Alex Koz. (Nov 01 2019 at 22:44, on Zulip):

I’m not sure and should check this out tomorrow.

Alex Koz. (Nov 06 2019 at 15:56, on Zulip):

Ok. That was mem-mapping.

Last update: Nov 16 2019 at 02:20UTC