Hi John, David,
I'm not a language lawyer, but just as a trifling technicality I gather the
void f(int m,int array[static m])
I was thinking that for certain targets, the knowledge of the static array size, allows for interesting optimizations, e.g. parallelized forms for accessing the interface array (ranging from single-element to simultaneous access of all elements, as would a partial or full unroller permit). If the compile-time known size information cannot propagate in the IR, then this opportunity is lost.
David, your approach offers a way to circumvent the problem from a software view (and spilling to a large stack/heap). I guess it will work with C99. It might also be directly usable in a JIT setting, however, in general, the m argument (size) will not be known at compile time.
For a hardware target, an LLVM procedure (CDFG) would be implemented as control+datapath block, by a high-level synthesis mapping process to a model of computation such as an FSMD (Finite-State Machine with Datapath).
then "the value of the corresponding actual argument shall provide access to
the first element of an array with at least as many elements as specified by
the size expression". So you might get user code using this construct whence
the compiler is entitled to expect a minimum size.
I agree and will put it to test in order to check how it is mapped to the IR.
But that's realy quite a
weak requirement, and it's also the wrong way round ("at least as big as"
rather than "not bigger than").
Yes, the hard requirement for the case i'm thinking is indeed "not bigger than"; a static limit that should not be surpassed. The memory model i assume is segmented (physically), each array is mapped into physically separate storage, and by default array layout is not further optimized. For safe accesses, scratch storage or spilling to slower memory (external memory if using an FPGA-based system) would be needed, but either option has its disadvantages. Defining also a default static size for bounds checking would be arbitrary (would usually be too large or too small).