<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div><blockquote type="cite" class=""><div class="">On Aug 1, 2017, at 2:58 PM, John McCall <<a href="mailto:rjmccall@apple.com" class="">rjmccall@apple.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><blockquote type="cite" class=""><div class=""><br class="Apple-interchange-newline">On Aug 1, 2017, at 9:53 AM, Daryle Walker <<a href="mailto:darylew@mac.com" class="">darylew@mac.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div class=""><blockquote type="cite" class=""><div class="">On Jul 31, 2017, at 4:37 PM, Gor Gyolchanyan <<a href="mailto:gor.f.gyolchanyan@icloud.com" class="">gor.f.gyolchanyan@icloud.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;">Well, yeah, knowing its size statically is not a requirement, but having a guarantee of in-place allocation is. As long as non-escaped local fixed-size arrays live on the stack, I'm happy. 🙂</div></div></blockquote><br class=""></div><div class="">I was neutral on this, but after waking up I realized a problem. I want to use the LLVM type primitives to implement fixed-size arrays. Doing a run-time determination of layout and implementing it with alloca forfeits that (AFAIK). Unless the Swift run-time library comes with LLVM (which I doubt). Which means we do need compile-time constants after all.</div></div></div></blockquote><div class=""><br class=""></div>We are not going to design the Swift language around the goal of producing exact LLVM IR sequences. If you can't phrase this in real terms, it is irrelevant.</div></div></blockquote><br class=""></div><div>It isn’t being LLVM-specific, but for any similar system. The instruction generator has certain primitives, like 16-bit integers or 32-bit floats. LLVM (and probably rivals) also has aggregate primitives, heterogenous and homogenous (and the latter as standard and vector-unit). I want to use those primitives when possible. Saving sizing allocations until run-time, after it’s too late for sized-array-specific generated instructions, means that the array is probably implemented with general buffer pointer and length instructions. Any opportunities for IR-level optimization of the types is gone.</div><div><br class=""></div><div>How often do you expect a statically sized array to need said size determined at run-time (with a function) versus a compile-time specification (with an integer literal or “constexpr” expression)? This may enable a 1% solution that anti-optimizes the 99% case.</div><br class=""><div class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">— </div><div class="">Daryle Walker<br class="">Mac, Internet, and Video Game Junkie<br class="">darylew AT mac DOT com </div></div></div><br class=""><div><blockquote type="cite" class=""></blockquote></div></div></body></html>