[swift-evolution] [Pitch] Swift needs fixed-size array
Karl Wagner
razielim at gmail.com
Mon Apr 17 17:51:33 CDT 2017
> On 18 Apr 2017, at 00:29, Karl Wagner <karl.swift at springsup.com> wrote:
>
>
>> On 17 Apr 2017, at 23:18, Michael Ilseman via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>>
>> This is the best approach that I’m aware of. It does bake in an ABI assumption that the tuple layout will be contiguous and strided/addressable. Monitor https://bugs.swift.org/browse/SR-3726 <https://bugs.swift.org/browse/SR-3726> for changes here. Note that you can also a little more “pure” in a sense if you construct an UnsafeBufferPointer from your UnsafeRawPointer and operate on that. Currently, the compiler does not always elide the copy in the getter, see https://bugs.swift.org/browse/SR-4581 <https://bugs.swift.org/browse/SR-4581>
>>
>
> Will the compiler ever optimise an UBP allocation on to the stack? For example, I’ve written plenty of code such as:
>
> let ptr = UnsafeRawBufferPointer.allocate(count: 128)
> defer { ptr.deallocate(count: 128) }
>
> ...when interfacing with C APIs. Which is basically the definition of a stack allocation. That would perhaps be the “swiftier” way to do it; to let the compiler determine how to allocate the memory based on what it knows about its expected lifetime.
I’ll answer that: no, it won’t.
echo "let ptr = UnsafeMutableRawPointer.allocate(bytes: 128, alignedTo: 1); defer { ptr.deallocate(bytes: 128, alignedTo: 1) }" | swiftc -O -emit-assembly -
.section __TEXT,__text,regular,pure_instructions
.macosx_version_min 10, 9
.globl _main
.p2align 4, 0x90
_main:
pushq %rbp
movq %rsp, %rbp
movl $128, %edi
xorl %esi, %esi
callq _swift_rt_swift_slowAlloc ; a.k.a. ‘malloc'
movq %rax, __Tv4main3ptrSv(%rip)
movl $128, %esi
xorl %edx, %edx
movq %rax, %rdi
callq _swift_rt_swift_slowDealloc ; a.k.a ‘free'
xorl %eax, %eax
popq %rbp
retq
Would be cool to do one day, though.
- Karl
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170418/97c137ba/attachment.html>
More information about the swift-evolution
mailing list