Most AVX/AVX2 functions not exposed

[jackmott]

Is this because they make use of long double ?
What work needs to be done to get those added? Happy to help.

[gnzlbg]

Yes, but there is no way to use long double from Rust, so I don't see that anything can be done to expose these.

[gnzlbg]

cc @joshtriplett long double on FFI is another feature that the FFI WG should at some point tackle. It's impossible to call functions with long double because the "call ABI" of the type cannot be emulated.

[jackmott]

Gothca, maybe I Will stroll over to the FFI WG and see if I can help there. In the mean time, I can use the sse4 functions twice, I suppose!

[gnzlbg]

We can also write a C wrapper that uses double and converts from double to long double or similar.

…

On Wed 13. Nov 2019 at 21:07, Jack Mott ***@***.***> wrote: Gothca, maybe I Will stroll over to the FFI WG and see if I can help there. In the mean time, I can use the sse4 functions twice, I suppose! — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#16?email_source=notifications&email_token=AAG43JXLZPAXNYSX6RZKYX3QTRM7HA5CNFSM4JMDGAWKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOED7PHLQ#issuecomment-553579438>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAG43JRAISVI7CAHINKHPG3QTRM7HANCNFSM4JMDGAWA> .

[greatest-ape]

Modifying sleef-sys slightly enables using, at the very least, this sleef avx function (coincidentally in a fork of @jackmott's crate). I don't know exactly how this relates the long double problem, but I thought I'd mention it anyway.

[greatest-ape]

I put it behind a feature flag here: greatest-ape@df02548

[greatest-ape]

@jackmott Only two functions actually take long double arguments: Sleef_sincospil_u05 and Sleef_sincospil_u35 (except for some in the DFT part of sleef which isn't currently compiled). I suspect the reason you're not seeing many AVX/AVX2 functions is that they are only compiled when avx is enabled as a target feature when compiling sleef-sys. #21 should fix this issue, if @gnzlbg is interested in merging it.

[greatest-ape]

I'm sorry about the multitude of comments, but for future reference/other readers, I suspect the ABI issue is discussed in:

• repr(simd) is unsound in C FFI rust-lang/rust#53346
• Tracking issue for RFC 2574, "SIMD vectors in FFI" rust-lang/rust#63068
• https://github.com/rust-lang/rfcs/blob/master/text/2574-simd-ffi.md

Progress seems to have stalled on rust-lang/rust#59238, which would implement RFC2574.

In my understanding, my pull request #21 works at some platforms when used carefully, but soundness issues would occur when let's say a function taking a 256 bit wide vector is called on a CPU only supporting 128 bit wide vectors. A fix might be to somehow add

#[target_feature(enable = X)] in C FFI functions using SIMD types

(to quote the RFC) to all relevant functions in sleef-sys, e.g. X=avx for SIMD type __m256.