Alternative implementations of some of the functions in src/numbers/conversions-inl.h for x86_64

26 views
Skip to first unread message

John Platts

unread,
Oct 28, 2022, 9:03:50 AM10/28/22
to v8-dev
I have written alternative implementations of the DoubleToInteger, DoubleToWebIDLInt64, DoubleToInt32, FastD2UI, IsInt32Double, and IsUint32Double functions in src/numbers/conversions-inl.h for x86_64 using SSE2 intrinsics.

I have done some benchmarking, and my alternative implementations of DoubleToInteger, DoubleToWebIDLInt64, FastD2UI, IsInt32Double, and IsUint32Double outperform the current implementations of DoubleToInteger, DoubleToWebIDLInt64, FastD2UI, IsInt32Double, and IsUint32Double in the src/numbers/conversions-inl.h on x86_64 platforms.

My alternative implementation of DoubleToInt32 has similar performance to the existing implementation of DoubleToInt32 in src/numbers/conversions-inl.h for values that are within the range of a 32-bit signed integer, and my alternative implementation of DoubleToInt32 is much faster for values that are outside of the range of a 32-bit signed integer.

I also would like to add an option to enable compiling with the existing implementations of the functions src/numbers/conversions-inl.h instead of my alternative implementations of these functions on x86_64 platforms.

My alternative implementation of the DoubleToWebIDLInt64, DoubleToInt32, FastD2UI, IsInt32Double, and IsUint32Double methods has dependencies on the _mm_cvttsd_si64 and _mm_cvtsi64_sd intrinsics that are not available on 32-bit x86 targets (including 32-bit x86 targets that have SSE2 support).

How do I add an option that would allow V8 to be compiled with my alternative implementations of the conversion methods in src/numbers/conversions-inl.h instead of the existing methods in src/numbers/conversions-inl.h (and vice versa)?

msle...@chromium.org

unread,
Nov 21, 2022, 1:11:31 PM11/21/22
to v8-dev
If it's an option for you to maintain an own fork of V8, then extending the header with the versions you have and putting them behind a compile-time macro might be a good choice. Otherwise I'd suggest trying to upstream your changes via submitting a pull request to https://chromium-review.googlesource.com/ (feel free to check out the contributing guide).

Jakob Kummerow

unread,
Nov 21, 2022, 1:40:44 PM11/21/22
to v8-...@googlegroups.com
We already have a Gerrit review for this: https://chromium-review.googlesource.com/c/v8/v8/+/3992117


--

Reply all
Reply to author
Forward
0 new messages