Identify features of stk_simd not yet implemented

[ibaned]

• [ ] full set of comparison and equality operators between simd types
• [ ] full set of boolean operators between simd_mask types
• [ ] aligned loads
• [ ] strided loads
• [ ] operator[] for simd types
• [x] abs
• [ ] sin, cos, tan, sinh, cosh, tanh, asin, acos, atan
• [x] cbrt
• [ ] log, log10, exp, pow
• [x] copysign
• [ ] isnan
• [x] fmadd, fused multiply-add (this is likely outside ISO space)
• [x] multiplysign (this is likely outside ISO space)

[alanphumphrey]

Thanks @ibaned for putting this together. I'll fully transition to this effort early next week as mentioned. What did you discuss with Christian in terms of what could potentially be proposed to C++ standards committee?

[ibaned]

@alanw0 @tasmith4 can you comment on whether all of these are actually needed? I know Sierra/SM has transitioned to the library already.

[alanw0]

I think sierra's current needs are pretty much met at this point, as are Sparc's and Exawind's. (Those are the only codes I know of using stk_simd.) For completeness it might be nice to get them all, but I wouldn't say it's urgent at this point.

[crtrott]

We need [] for compatibility for C++ simd types

[alanw0]

Oh I might have been a little confused... this is the list of stuff that would be needed before stk_simd users can abandon stk_simd and use kokkos_simd? In that case I need to look a little deeper and assess where we are at.

[ibaned]

@alanw0 yea that's the goal here, so we should include things that are somehow provided by the stk_simd wrapper layer as well.

[tasmith4]

I think we do need everything on this list in order to replace stk_simd. In addition to the math functions you listed above, stk_simd also provides atan2, asinh, acosh, atanh, and erf (I'm not sure how much usage we have of those, but they are in our API). We also definitely need operator[] as I believe both Sierra and SPARC depend on this.

Another thing we provide to users of stk_simd is the ability to pass a compile-time macro (USE_STK_SIMD_NONE) that forces scalar SIMD no matter what instruction set would normally get picked up. The Sierra app teams find this helpful for debugging. I didn't see a corresponding feature in this repo, but please let me know if I missed something.

stk_simd builds also enable by default the STK_VOLATILE_SIMD macro, which turns on functions for compatibility with usage of volatile in Kokkos::parallel_for (recall the discussion here). I don't think it's essential to abandoning stk_simd, but in my dream world we would be able to get this resolved so Sierra users don't have to turn on this macro in a bunch of places around the build system.

There is a weird interaction with some of the functions such as cbrt that are implemented with Intel SVML functions where we can't just pass through e.g. to SIMD_NAMESPACE::cbrt when using scalar SIMD. Not sure if this is a fundamental issue or an interaction with the stk_math library, which also provides scalar versions of these operations. I imagine this would be clarified when putting together unit tests as mentioned in #21, so just a headsup here to be on the lookout for that.