> On Aug 1, 2017, at 2:58 PM, John McCall <[email protected]> wrote: > >> >> On Aug 1, 2017, at 9:53 AM, Daryle Walker <[email protected] >> <mailto:[email protected]>> wrote: >> >>> On Jul 31, 2017, at 4:37 PM, Gor Gyolchanyan <[email protected] >>> <mailto:[email protected]>> 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 [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
