-
Notifications
You must be signed in to change notification settings - Fork 101
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
std::arch SIMD intrinsics #171
Comments
Cranelift doesn't have intrinsics. It does have simd types, which can be used with normal instructiosn like
Not yet, have been thinking about adding one though. |
@bjorn3 check this out: https://github.com/rust-lang-nursery/stdsimd/blob/master/coresimd/x86/sse.rs#L1986 This is how
That sounds more like what It might be easier to get Even if this work is not there yet, I think work to "prepare" Removing |
|
Not without changes to
+1 |
What would be desirable to start preparing @eddyb was of the strong opinion that The lowest-hanging fruit is probably to get |
I don't think littering stdsimd with |
Using |
I like the idea. There is currently an abi incompatibility between |
I am not sure if these are necessary for an MVP of |
Yeah I suspect any upstreamed backend to use e.g. |
I don't understand what to do when getting |
You're supposed to pass the type's bytes as one or more immediates, as indicated by the information in the cast (e.g. |
Got it. Thanks! |
I implemented support for some |
I suppose that doing a scalar emulation might be initially ok, but doesn't cranelift support emitting the appropriate instructions? |
Yes, it does for most intrinsics, but cranelift is currently implementing real simd, instead of emulation like I did here. (bytecodealliance/cranelift#833, bytecodealliance/cranelift#855, bytecodealliance/cranelift#868) Because of this I think for example adding two vectors is broken. (cc @abrown, am I correct?) Also using real SIMD will not give much performance benifit yet, until some changes to the rest of cg_clif to not always store the vectors on the stack are performed and inlining of the |
I think this is only broken if you turn on the |
Of cource, forgot about that setting. |
Opened #650. |
https://github.com/bjorn3/rustc_codegen_cranelift/pull/1378 and https://github.com/bjorn3/rustc_codegen_cranelift/pull/1380 implemented a bunch more intrinsics. |
Enough intrinsics are supported now that it seems like removing the hack to make |
#1417 implemented a lot of intrinsics that were found to be missing. |
So I'm testing cranelift a bit in our group, so far we've hit these missing instructions. Not sure there's a workaround for that right now. Also curious how people figure out what dep is calling these, and how to best track when PRs land in rust nightly
I think the first one might be fixed by #1417. Loving cranelift where we can use this though! |
I just get a backtrace at the crash site using a debugger.
I will post a comment in the respective issue once it lands on nightly.
For the aes intrinsics you can use |
FWIW, I went with a simple This should be simpler, as it doesn't burden you with running the code and trying to hit the traps. And also, there could be more than one dependency using the same missing intrinsics reported, so run and debug may miss some usage cases in dependencies. |
For making the codegen production-ready I think it's important to fail compilation when an unsupported intrinsic is hit. The replacement with a trap should be opt-in (probably only through a debug env var) for a safe behaviour. Think about not noticing a regression from a crate update in a build/release pipeline because there is just this warning instead of failing compilation hard. Edit: Also, IDE users might easily miss the warning if the IDE triggers the compilation in the background. |
Rustc_codegen_cranelift is meant for use during development. For release builds I recommend the default LLVM backend or in the future the GCC backend as both produce much faster executables. In the future I agree that it makes sense to turn this into a hard error by default, but until there are enough simd intrinsics implemented for that to rarely result in a compile error, I did rather keep it as warning + trap at runtime. |
#1443 by @Nilstrieb implemented a couple of x86 pack intrinsics and fixed a couple other of these intrinsics. |
Currently the SIMD intrinsics are implemented in
stdsimd
usinglink_llvm_intrinsics
to directly call the llvm intrinsics via their C ABI, and using a handful of "generic" simd intrinsics.Is there a way to directly call Cretonne intrinsics?
Is there a
cfg()
macro available to detect whether the codegen backend is LLVM or Cranelift ?The text was updated successfully, but these errors were encountered: