-
Notifications
You must be signed in to change notification settings - Fork 5.8k
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
Implement KT-73565 and basic box tests for memcpy, memmove, memset and memcmp intrinsics #5385
base: master
Are you sure you want to change the base?
Conversation
Adding some changes to this, i wasn't happy with the names of the extension functions for |
import kotlin.collections.set | ||
import kotlin.collections.sortedBy | ||
import kotlin.collections.toList | ||
import kotlin.collections.toTypedArray |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Don't know why my formatter did this with the project settings.. can fix if desired.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, please.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks! Great work overall, but it requires a few minor adjustments :)
@@ -90,6 +98,65 @@ internal object nativeMemUtils { | |||
fun copyMemory(dest: NativePointed, length: Int, src: NativePointed) = | |||
unsafe.copyMemory(src.address, dest.address, length.toLong()) | |||
|
|||
fun memset(mem: NativePointed, value: Byte, size: Int) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There is no need to add intrinsics to the JVM interop as they are unused there.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Huh, it didn't compile without them for me in my personal fork, that's odd. Will remove ^^
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah i have to add them there too it seems, at least if i want to add this to nativeMemUtils, the code does not compile when the functions are not defined in both files. Everything breaks :/
import kotlin.collections.set | ||
import kotlin.collections.sortedBy | ||
import kotlin.collections.toList | ||
import kotlin.collections.toTypedArray |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, please.
@@ -391,8 +419,14 @@ internal class StackLocalsManagerImpl( | |||
val bbInitStackLocals: LLVMBasicBlockRef | |||
) : StackLocalsManager { | |||
private var scopeDepth = 0 | |||
override fun enterScope() { scopeDepth++ } | |||
override fun exitScope() { scopeDepth-- } | |||
override fun enterScope() { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A nitpick: it is usually a good idea to separate formatting changes from actual ones. Beyond other things, it makes review easier :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fair enough, will keep that in mind. I'm just way too used to hitting CTRL+ALT+L after everytime i finish writing something somewhere hahaha.
@TypedIntrinsic(IntrinsicType.INTEROP_READ_PRIMITIVE) external fun getDouble(mem: NativePointed): Double | ||
@TypedIntrinsic(IntrinsicType.INTEROP_WRITE_PRIMITIVE) external fun putDouble(mem: NativePointed, value: Double) | ||
@TypedIntrinsic(IntrinsicType.INTEROP_SET_MEMORY) | ||
external fun memset(mem: NativePointed, value: Byte, size: Int) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why do we need both 32 and 64-bit versions? Are they equally portable?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
From what i know about LLVM, they should be equally portable.
However, there's a reason why i split them up:
All major native platforms apart from some mobile and embedded applications are 64-bit now.
Using 64-bit everywhere for things like memcpy could waste CPU cycles for applications where 64-bits will never be used (since this affects the internal index size of the intrinsic implementation afaik), like when copying between native memory <-> kotlin arrays, only if it's probably very little.
It is still important to offer the 64-bit API to allow utilizing the full capability of the host CPU when working with unmanaged memory.
If you want, we can drop the small 32-bit optimization entirely and just cast to 64-bit size types when dealing with things like arrays etc.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I could be wrong to be honest, will look into this a little deeper.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
All major native platforms apart from some mobile and embedded applications are 64-bit now.
Unfortunately, we still have 32-bit targets, and providing 64-bit API for them might be wrong.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Then we should offer both, since Kotlin does not have a size type, i think. 32-bit only is very mediocre for more serious applications imo.
} | ||
|
||
@ExperimentalForeignApi | ||
public fun copyMemory(destMem: NativePointed, srcMem: NativePointed, size: Long) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we really need both moveMemory and copyMemory functions? The second one is less safe and performance benefits might not worth it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No real reason i added memmove apart from "might as well complete the set of three" when i was reading the LLVM manual to look up the copy intrinsic. Can remove if you want :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yep, I tend to think that memmove
should be sufficient for now.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hm, not entirely happy with that to be honest, since 99% of the time you'd use memcpy, not memmove but that works.
} | ||
|
||
@ExperimentalForeignApi | ||
public inline fun <reified T : CVariable> CPointer<T>.compareBlock(dest: CPointer<T>, length: Int): Int { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe compareContentsWith
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I like that, will change.
} | ||
|
||
@ExperimentalForeignApi | ||
public inline fun <reified T : CVariable> CPointer<T>.setBlock(value: Byte, length: Int) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe just fillWith
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Also a good name, will change.
@@ -727,3 +735,43 @@ public fun COpaquePointer.readBytes(count: Int): ByteArray { | |||
nativeMemUtils.getByteArray(this.reinterpret<ByteVar>().pointed, result, count) | |||
return result | |||
} | |||
|
|||
@ExperimentalForeignApi | |||
public fun setMemory(mem: NativePointed, value: Byte, size: Long) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could you please add a small KDoc for all new public functions?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Will do!
data1.usePinned { pinned -> | ||
pinned.addressOf(0).setBlock(0, data1.size) | ||
} | ||
if (data1.contentEquals(data2)) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Checking the new value directly would be more robust.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
True, will fix.
import kotlin.test.* | ||
import kotlinx.cinterop.* | ||
|
||
fun box(): String { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please add tests for top-level functions as well.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good point, don't know why i didn't think of that, will add.
Will update this in the following days, was a little busy this weekend :) |
As described in the associated YouTrack issue, this PR aims to add memory intrinsics for Kotlin/Native for functions such as memset, memcpy, memmove and memcmp (throught libc). This allows optimizing a lot of per-element loop based functions with much faster optimized code.
I also implemented a public API for the intrinsics, supporting both untyped NativePointed addresses, and type safe extension functions for
CPointer
.Very basic tests have been implemented in
kt73565.kt
for every function to make sure they work.If you have any comments or nitpicks, feel free to let me know.
Cheers.