> 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
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.
Mac, Internet, and Video Game Junkie
darylew AT mac DOT com
swift-evolution mailing list