> On Aug 1, 2017, at 2:58 PM, John McCall <rjmcc...@apple.com> wrote:
>> On Aug 1, 2017, at 9:53 AM, Daryle Walker <dary...@mac.com 
>> <mailto:dary...@mac.com>> wrote:
>>> On Jul 31, 2017, at 4:37 PM, Gor Gyolchanyan <gor.f.gyolchan...@icloud.com 
>>> <mailto:gor.f.gyolchan...@icloud.com>> wrote:
>>> 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. 🙂
>> 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.
> 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.

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.

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.

Daryle Walker
Mac, Internet, and Video Game Junkie
darylew AT mac DOT com 

swift-evolution mailing list

Reply via email to