[DO NOT MERGE] Add subtraction, rounding avx instrs - #42
Conversation
Adds subpd256, subps256, roundpd256, ceilpd256, floorpd256, and associated tests
We can use the generic operators instead
|
Thanks for the PR! What do the test failures look like if you add |
My intrinsics reference says there is something for VROUNDPD, though I'm not 100% sure how I should proceed; I've tried some permutations on the name of the intrinsic. |
|
I think this means that the argument must be an immediate? Right now it takes an i32, but should it take a byte instead? |
|
I've tried it with both an i8 and a u8, which both fail to compile. It looks like the icc intrinsic takes a c-int (http://www.felixcloutier.com/x86/ROUNDPD.html). Does the immediate have to be a constant expression? |
|
Ah yeah you'll find a few macros (I think |
Tests are still up in the air because of #49.
|
@alexcrichton We should be good to go now; the broken appveyor build appears to be unrelated to this change. |
|
Looks great, thanks @AdamNiederer! |
…n, r=petrochenkov Prevent name collisions with internal implementation details The implementation of the linkage attribute inside extern blocks defines symbols starting with _rust_extern_with_linkage_. If someone tries to also define this symbol you will get a symbol conflict or even an ICE. By adding an unpredictable component to the symbol name, this becomes less of an issue. Spawned from the discussion at [#t-compiler > About static variables `_rust_extern_with_linkage_*`](https://rust-lang.zulipchat.com/#narrow/channel/131828-t-compiler/topic/About.20static.20variables.20.60_rust_extern_with_linkage_*.60) cc `@ywxt` Fixes rust-lang/rust#144940
Hi all,
I've implemented subpd256, subps256, roundpd256, ceilpd256, floorpd256, and their associated tests. It's still a bit of a work in progress
I'll try to iron those out tomorrow.