Stream: t-compiler

Topic: simd in const fn


gnzlbg (Sep 25 2019 at 07:40, on Zulip):

@oli so i'm not 100% sure that miri is the right place for the const fn intrinsics

gnzlbg (Sep 25 2019 at 07:40, on Zulip):

I actually started implementing it there, but the "intrinsics" being matched there are more like FFI calls and such

oli (Sep 25 2019 at 07:41, on Zulip):

yes, just like in codegen

oli (Sep 25 2019 at 07:41, on Zulip):

miri is more like codegen and less like const eval

gnzlbg (Sep 25 2019 at 07:41, on Zulip):

yeah

oli (Sep 25 2019 at 07:41, on Zulip):

what I'm saying is that you can literally run your normal code using those intrinsics in miri

gnzlbg (Sep 25 2019 at 07:41, on Zulip):

so right now the simd intrinsics are quite tied to the llvm codegen backend

gnzlbg (Sep 25 2019 at 07:41, on Zulip):

yes, but IIUC that would also work by putting them in const eval right ?

oli (Sep 25 2019 at 07:41, on Zulip):

and once all that works nicely (you'll be iterating faster on miri than on rustc), we can move to rustc

gnzlbg (Sep 25 2019 at 07:42, on Zulip):

I see

oli (Sep 25 2019 at 07:42, on Zulip):

yes, but we don't put things in const eval that aren't RFCed unless there's a very good reason

gnzlbg (Sep 25 2019 at 07:42, on Zulip):

so, maybe we could FCP these ?

oli (Sep 25 2019 at 07:42, on Zulip):

in miri we'll be much more lenient with hacks and stuff

gnzlbg (Sep 25 2019 at 07:42, on Zulip):

I mean we want to support these properly at some point

gnzlbg (Sep 25 2019 at 07:42, on Zulip):

IIRC we already handle simd_shuffles somewhere in there for some reason

oli (Sep 25 2019 at 07:43, on Zulip):

sure, but you can't really test them without higher level changes

gnzlbg (Sep 25 2019 at 07:43, on Zulip):

(or at least I've seen simd_shuffle in the const eval code)

oli (Sep 25 2019 at 07:43, on Zulip):

that's not in const eval

oli (Sep 25 2019 at 07:43, on Zulip):

we const eval the simd shuffle args

oli (Sep 25 2019 at 07:43, on Zulip):

that's different

gnzlbg (Sep 25 2019 at 07:43, on Zulip):

ah, yes that makes sense, they must be constant

oli (Sep 25 2019 at 07:44, on Zulip):

so the reason I don't want this in const eval is because I hate the test that you added. Not because of the content, but because of the unleash and other errors

gnzlbg (Sep 25 2019 at 07:44, on Zulip):

yes

oli (Sep 25 2019 at 07:44, on Zulip):

it is really hard to differentiate between actual hacks and incomplete or broken things

oli (Sep 25 2019 at 07:44, on Zulip):

in miri you can do this cleanly

oli (Sep 25 2019 at 07:44, on Zulip):

no hacks needed

oli (Sep 25 2019 at 07:44, on Zulip):

no intermingling with const fn

gnzlbg (Sep 25 2019 at 07:44, on Zulip):

wait, can't we just say that these intrinsics are const fn ?

gnzlbg (Sep 25 2019 at 07:44, on Zulip):

like when doing extern "platform-intrinsics" { ... }

oli (Sep 25 2019 at 07:45, on Zulip):

You are using the word "just" just like I'm using it often and I don't think it means what we use it for

gnzlbg (Sep 25 2019 at 07:45, on Zulip):

can I just say const fn simd_insert ?

oli (Sep 25 2019 at 07:45, on Zulip):

and no that doesn't work ;)

gnzlbg (Sep 25 2019 at 07:45, on Zulip):

so what would be required to test these without unleash ?

gnzlbg (Sep 25 2019 at 07:46, on Zulip):

I mean, I think what I want is to make these true const fns

oli (Sep 25 2019 at 07:46, on Zulip):

you need to add them to the big list of const evaluable intrinsics, grep for "size_of" (including quotes), there aren't that many uses of it and one of them is the list

oli (Sep 25 2019 at 07:46, on Zulip):

ok, yea, we could add them to the list

gnzlbg (Sep 25 2019 at 07:46, on Zulip):

ah, yes, I think I've seen that list (I added the is_const_eval thingy there by mistake)

gnzlbg (Sep 25 2019 at 07:47, on Zulip):

so looking at all the simd intrinsics that we have

gnzlbg (Sep 25 2019 at 07:47, on Zulip):

I think that most of them can be added to the list

gnzlbg (Sep 25 2019 at 07:47, on Zulip):

see https://github.com/rust-lang-nursery/packed_simd/blob/master/src/codegen/llvm.rs#L9 for the list

oli (Sep 25 2019 at 07:47, on Zulip):

kind of overlapping with https://github.com/rust-lang/rust/pull/61835 but that should be manageable

gnzlbg (Sep 25 2019 at 07:47, on Zulip):

and there: https://github.com/rust-lang-nursery/packed_simd/blob/master/src/codegen/llvm.rs#L51

gnzlbg (Sep 25 2019 at 07:48, on Zulip):

most of them are just "add", "eq", etc.

gnzlbg (Sep 25 2019 at 07:48, on Zulip):

there are some tricky ones though, e.g., simd_select does a branch, but both arguments are always evaluated

oli (Sep 25 2019 at 07:48, on Zulip):

I so want these to have const generics </offtopic>

gnzlbg (Sep 25 2019 at 07:49, on Zulip):

yes that would improve their API

gnzlbg (Sep 25 2019 at 07:49, on Zulip):

the plan is not to expose any of these

oli (Sep 25 2019 at 07:49, on Zulip):

so in miri you only need one impl for all of these

gnzlbg (Sep 25 2019 at 07:49, on Zulip):

but to use them internally in core to implement normal Rust wrappers that expose the functionality in a stable way

oli (Sep 25 2019 at 07:49, on Zulip):

because you can extract the index from the name ;)

gnzlbg (Sep 25 2019 at 07:49, on Zulip):

you mean the shuffles ?

gnzlbg (Sep 25 2019 at 07:50, on Zulip):

I think we should refactor them in the llvm_codegen_backend at some point anyways

oli (Sep 25 2019 at 07:50, on Zulip):

yes

gnzlbg (Sep 25 2019 at 07:50, on Zulip):

the way it is currently done isn't great

gnzlbg (Sep 25 2019 at 07:51, on Zulip):

I think we can probably just make the array a generic parameter

gnzlbg (Sep 25 2019 at 07:51, on Zulip):

even without const generics

oli (Sep 25 2019 at 07:51, on Zulip):

heh or that

gnzlbg (Sep 25 2019 at 07:51, on Zulip):

but nobody has bothered

oli (Sep 25 2019 at 07:51, on Zulip):

ok, so I'd be fine with unstably adding these intrinsics just like in your PR, as long as the tests don't need unleash, but just a feature gate

gnzlbg (Sep 25 2019 at 07:52, on Zulip):

so appart from simd_select, then there are also scatter and gather: https://github.com/rust-lang-nursery/packed_simd/blob/master/src/codegen/llvm.rs#L97

oli (Sep 25 2019 at 07:52, on Zulip):

well... I don't want to see 5 impls of the same intrinsic in const eval :P whatever solves that is fine with me for now

gnzlbg (Sep 25 2019 at 07:52, on Zulip):

these take a vector of pointers, and dereferences them

gnzlbg (Sep 25 2019 at 07:53, on Zulip):

@oli I suppose i can match s.starts_with("simd_shuffle") and save some boilerplate

oli (Sep 25 2019 at 07:53, on Zulip):

oh matching on all names is fine

oli (Sep 25 2019 at 07:53, on Zulip):

as long as the code is just one arm

gnzlbg (Sep 25 2019 at 07:54, on Zulip):

for the vector of pointers, I don't know if need extra care, like gating that on a feature gate or something

gnzlbg (Sep 25 2019 at 07:54, on Zulip):

there was a gate for pointers in const fn, so it might make sense to reuse that

gnzlbg (Sep 25 2019 at 07:55, on Zulip):

these are all going to be scalarized internally, so since the operations for pointer dereference are already feature-gated, then this might not be necessary

gnzlbg (Sep 25 2019 at 08:29, on Zulip):

@oli so I've pushed a commit that removes the need for -Zunleash

gnzlbg (Sep 25 2019 at 08:29, on Zulip):

other than that, could you let me know if that PR uses Operand/OpTy/MPlace/Place/... correctly ?

Last update: Nov 22 2019 at 04:50UTC